Anticipar las necesidades de backend

You are at Gate 4 of the method. While the port runs, the backend waits.
Use that time to find out what the backend work will need from people
other than me, so that I ask for it now, not on the day I am blocked.

Read:
- the PRD, its flows, and section 11, the backend and API assumptions
- the backend conventions, and the backend code if there is any
- what was built ahead during Gate 3, if anything was, and the needs it
  already raised in the journal
- `docs/backend-requests.md`, if it exists
- the project memory and journal

The flows Gate 5 will connect, in this order:
[THE FLOWS, IN THE ORDER YOU WILL CONNECT THEM]

What I can already do myself — the platforms, consoles, environments
and tools I have access to, and with which rights:
[WHAT YOU HAVE ACCESS TO, or "I do not know"]

For each flow, in that order, list everything the backend work will
need that I cannot do myself: access to a platform or a console; a
permission or a role; a key, a secret or a service account; a resource
to create, such as a database, a queue, a storage bucket or a domain; a
change that needs rights I do not have, such as a migration, a network
rule or a setting in a shared environment; a deployment; an account with
an outside service; an API that does not exist yet. Section 11 of the
PRD already lists what to request from Ops: take in what it lists that
nobody has asked for yet, marked as coming from there, so that one list
holds every request.

Read only. Change no code, the front's or the backend's, and run
nothing: no sign-in, no command or request against a platform, an
environment or an API, no look at my credentials or at my tools'
settings to find out what I can do. Do not open environment, key or
certificate files; tell what a secret is for from the code that loads
it. Where you cannot tell whether I already have something, mark it
"to confirm", and ask me about all of them together, at the end.

Write each need as a request ready to send:
- what is needed, in one sentence the person can act on: in which
  environment, and no more access than the work needs
- for which flow, and why: what in the PRD, the conventions or the code
  shows it is needed
- when it is needed: the first flow it holds up; I add the date
- for how long, if it is not for good
- who can do it, if the PRD, the conventions or the memory say so;
  otherwise "owner to find"
- what I can move forward meanwhile, if anything
- the ticket: left empty, for me to fill in when I send it

Where a key or a secret is needed, ask for it to come the way that team
hands secrets over, never in the ticket.

Group the requests by who can do them, the earliest needed first.
Write them to `docs/backend-requests.md`; if the file exists, add to it
and keep what is there, ticket references included. No secret value,
there or anywhere else. Send nothing anywhere: I send the requests
myself, as tickets, in each team's own tool.

Then append an entry to the project journal saying what you listed and
what is still to confirm. State which gate you are at, what you have,
what is missing, and what I must decide before you cross. Saying what
you will do next is not permission to do it: you cross when I answer,
not when you announce.