What happens in serial library?

So, reading about it on the internet i could understand the UART communication in arduino uses 8 bit packages so it should be composed of 1 start bit, 5 data bit, 1 parity bit and 1 stop bit. But i still have some difficulties trying to visualize the data flow because:
As you transmit bytes one after the other is there a time in witch the data remains idle so it would be easier to identify the first and last bit? Or the software keeps counting the number of bits from 1 to 8 to better identify the last bit?
Because if there is any problem in the transmission, like a change in the start bit, would the software be able to find the start bit once again?
With those doubts i ended up thinking i could read the serial data bit by bit in the terminal to see how it goes and started trying the following:

boolean newData = false;
byte lastBuff=0;

void setup() {
  Serial.begin(9600);
  Serial.println("Connected");
  Serial.println("Baud: 9600 bits/s");

}

void loop() {
  if (Serial.available()>0){
    lastBuff=Serial.read();
    newData=true;
if (newData == true){
    Serial.println (lastBuff, BIN);
    newData=false;
  }
}

I think there is something very fundamental that i am not understanding because the program always returns 6 bits, starting with 11 and then the data received. Is there a way for me to see what are Serial.read and Serial.ready codes? I may be out of my depth but I really wouldlike to understand this

Yes.
They're called stop bits.

BIN suppresses leading zeroes.

Not quite.

See here for the possible combinations of start bits, data bits, stop bits and parity bits.

https://www.arduino.cc/reference/en/language/functions/communication/serial/begin/

The 8 bits refers to the number of data bits and does not include start, stop or parity bits, those are in addition to the data bits. In my industry (telecoms) they are called overhead bits because they an overhead to the data you want to transmit.

More usually 8 data bits and no parity bit.

The START bit is always HIGH and the STOP bit is always LOW so there is always a RISING edge to start the character.

The internal UART clock is typically running at 16 times the baud rate. After the rising edge (beginning of the START bit) is detected, the UART waits for 24 clocks (1.5 bits) and samples 'N' bits (usually 8 or 7) at 16-clock intervals. If there is no parity bit it waits one additional bit time (16 clocks) to sample the middle of the STOP bit. If the STOP bit is not LOW the UART reports a 'Framing Error'. It buffers the received character, signals for an interrupt, and goes back to waiting for a rising edge.

This is not quite correct - typically having seen the high to low transition signalling the beginning of the start bit, the USART will then delay until the centre of the start bit and then read three samples to ensure the start is valid, and not just a glitch.
Only then will the line be sampled every sixteen cycles, otherwise the USART will reset and look for the next start bit.

The START bit is always HIGH and the STOP bit is always LOW so there is always a RISING edge to start the character.

Um. Idle state on a TTL-level serial connection is HIGH. The start bit is a LOW...

Note that for a normal Serial port, a lot of what we are talking about here happens in HARDWARE, rather than in any software library. SoftwareSerial does similar things in software.

1 start bit, 8 data bits, 1 stop bit, unless you explicitly configure it otherwise.

As you transmit bytes one after the other is there a time in witch the data remains idle so it would be easier to identify the first and last bit?

That's what the "Stop bit" does. In theory, during the stop bit, the receiver "unsynchronizes" with the bit stream, which is part of what make Serial an "Asynchronous"; it will re-synch with the bit stream when it sees the next start bit...

Because if there is any problem in the transmission, like a change in the start bit, would the software be able to find the start bit once again?

It IS possible for a Serial port to get out-of-sync if there is continuous input. It'll see random zero bits withing a character, read the rest of the bits, perhaps decide that there's an error because the stop bit has the wrong value, but ... this can repeat for a while. Any idle time longer than one character time will reset things, though - looks like an all-ones character with a valid stop bit, and the port can start waiting for a start bit again.

i am not understanding because the program always returns 6 bits, starting with 11 and then the data received.

What characters are you sending? Lower case alphabetic characters and numeric digits both start with 11; they're encoded in "ASCII", which adds some extra bits.

Is there a way for me to see what are Serial.read and Serial.ready codes?

yeah; you have all the source code. It's not going to be particularly helpful for the sort of questions you're asking - like I said, a lot happens in hardware.
Serial.read() code (retrieves bytes that were previously stored in the rx complete interrupt service routine
SoftwareSerial Receive code

What might be more useful is some of the stuff written up at the dawn of the personal computing era, when they thought it was important for everyone to understand all those details. Maybe:
Best of Byte v1 (1977) page 27: "What is a Character"

This is a darn good read.
https://support.saleae.com/protocol-analyzers/analyzer-user-guides/using-async-serial

An amazing little tool, highly recommended esp for SPI and I2C issues.