Building a spec when you're locked out of the codebase

An associate PM described a specific, common frustration: every release, their job is to translate the API into the platform — but they're not allowed access to the codebase. So they manually audit the product, grab screenshots, and paste context into the model piece by piece. They asked how to let an agent actually traverse the platform and understand it against the API docs.

This is the locked-out version of grounding, and it's more solvable than it feels. You don't need the source code to start a spec from reality. You need the running product and the API contract, and both are things you have.

Two sources of ground truth you already have

• The live product. Every screen, action, and state is observable behavior. An agent that can navigate the product can build the same inventory the codebase would give you — actors, triggers, effects — without reading a line of source.
• The API documentation. The API is a contract: these endpoints exist, they take these inputs, they return these shapes. That's a precise description of what the system can do, independent of how it's coded.

Cross-reference those two and you have most of what repo access would have given you: what the product does (from behavior) and what it's capable of (from the API), which together tell you where the gaps and the new work are.

The loop that beats manual screenshotting

1. Have an agent traverse the live product, cataloguing screens, actions, and the state each produces — instead of you screenshotting by hand.
2. Feed it the API docs as the capability map: here's what the platform can do at the contract level.
3. Reconcile the two: which API capabilities are surfaced in the product, which aren't, and which product behaviors imply endpoints you should map. The gaps between observed behavior and documented capability are your spec's subject.
4. Write requirements from the reconciled picture, grounded in real product behavior and real contract, not in screenshots you assembled from memory.

Being locked out of the codebase is a real constraint, but it's not a wall. The code was never the only ground truth — it's just the most convenient one. The running product and the API are ground truth too, and a spec built from them starts from reality the same way a repo-baselined one does.