Bring in an existing codebase

You generated an application with an agent, it runs on your machine, and you cannot get it any further. makermap does not deploy it, scan it or read its code - it holds the list of what "done" means, the record of what you found, and the evidence that somebody checked. That turns out to be most of what is missing.

1. Create the product and ask what is owed

create_product name="My app"
get_intake_plan productId=...

The plan is an audit specification, one entry per layer: what to look for locally, which tool records the answer, and whether the layer is filled, owed or deliberately skipped. Run it yourself; makermap asks the question, your agent answers it.

2. Link the repository first

link_repository is the one channel that produces a fact. CI runs arrive as signals and can settle a gate condition on their own. Without it, every condition on every gate rests on somebody saying so - which is legitimate, and worth knowing about.

3. Answer what a repository can answer

Stack from the manifests, deployments from the Dockerfile and CI workflows, decisions from the ADRs and the clusters of TODO comments, the board from what the code complains about. Each has its own write in the plan.

Two things never come from the repository:

• The five "why" fields. An agent reading a README can produce a plausible product vision, and a plausible one is worse than an empty one, because nobody re-reads a field that looks filled in. Answer them yourself, or leave them empty and let them be reported.
• Credential values. If a live secret is committed, that is an incident to open and rotate, not a field to copy.

4. Declare what does not apply

Intake is finished when every layer is either filled or explicitly declared skipped - not when a product row exists. An empty milestone list is a legal state; an empty milestone list nobody mentioned is indistinguishable from one nobody thought about.

Record the deliberate ones in the product's intake-report document, one per line:

- [skip] marketing - nothing is sold to anybody yet
- [skip] financial - no money in this

5. Open a readiness checklist

list_gate_templates returns your workspace's own templates and, in systemChecklists, the six that ship with makermap: production-deploy, authentication, payments, security, automated-tests, store-submission. Each is what "done" means for that theme, written as conditions somebody can settle.

create_gate productId=... fromTemplate="production-deploy"

The gate reports assurance per condition and for itself: signal means makermap computed the result from data that reached it through a channel it owns; report means it is recorded because somebody said so, with their name on it. Evidence a caller labelled "integration" is still a report. A list that rendered both the same way would be lying about half of itself.

What this record can and cannot claim

It knows what should be checked, it remembers who checked it and when, and it tells you when that has gone stale. A passed security gate means somebody reported having looked. It is not a scan, and reading it as one is the mistake worth avoiding.