From project files to a readiness review

A readiness review answers a concrete question: what is missing before this revision can move to its next build? It should use the files you already have, then ask the founder for decisions those files cannot supply.

The production_readiness action creates a draft checklist with pass, gap and unknown entries. It does not inspect CAD, run a test or approve production. Your existing agent supplies the relevant facts and references.

1. Start with the revision and next build

Identify the product or assembly, current revision, intended next build and quantity. A request to quote an enclosure does not establish readiness of the complete electronic product.

Inventory the selected folder with the local context preview. Let your agent read permitted files with its existing tools. Keep filenames and revisions beside extracted facts; keep a manifest hash when you need to identify the exact file set. A hash identifies bytes, not engineering validity.

Save a project brief with the priorities, hard constraints and open questions. Update intake carefully: the API replaces that whole object when you supply it.

2. Reuse evidence before asking questions

For each topic, distinguish what exists from what the product needs:

Topic	Useful evidence	Ask only if missing
Design	Released drawing/BOM revision, change log	Which revision is authoritative?
Critical quality	Measurable limits and inspection method	What must never be traded for lower cost?
Materials and parts	Exact part/material, quantity, approved alternatives	Who can approve substitutions?
Tests	Report, tested revision, method and results	Which failures or untested requirements block this build?
Build process	Assembly, programming, calibration and inspection instructions	Who will supply the missing process or fixture?
Release	Named decision owner and acceptance evidence	Who decides that the next build may start?
Delivery	Cargo, destination, timing and applicable document evidence	Which logistics decisions remain open?

Do not ask the founder to retype a BOM. Do not turn “we plan to test it” into “test passed.” If an owner or date has not been agreed, keep it unknown rather than inventing one.

The founder interview can collect a small initial brief. The readiness action uses the richer project context and answers you explicitly send; it is a separate operation.

3. Submit the known facts and gaps

The synthetic project example includes a BOM, requirements, a project brief and readiness.json. The material is proposed, tolerances are missing, and no completed test is supplied. It is intentionally incomplete.

After creating its project, use the returned ID:

maglev actions request PROJECT_ID \
  --input examples/agent-project/readiness.json \
  --idempotency-key example-revision-a-readiness-001 --json

Use answers as a map of topic names to text. Preserve exact facts, sources and explicit gaps. A local path in an answer is only a reference: Maglev does not fetch that file. This request sends the answer text for storage and AI processing.

Read the action schema before extending the request. Unsupported top-level fields may be discarded by the server. Keep a new revision’s request under a new idempotency key.

4. Review each item

The response holds the review in action.output.result. Check action.status first: action.output can be null while running or after a failure. A saved output also includes draft: true and a note.

Field	How to use it
items[].status	Check the proposed pass, gap or unknown against the supplied evidence
items[].evidence	Trace the assertion to an actual answer or source; null means no evidence was supplied
items[].nextStep	Turn the missing information into a specific task with an agreed owner
blockers	Review which gaps actually prevent the intended build
assumptions, openQuestions	Preserve these when handing the work to engineering or a factory
sources	Identify grounding passages used by the model; these are not your product’s test records

Reject an unsupported pass, a borrowed supplier fact or a question about hardware the project does not contain. A completed readiness request returns action.status: draft_ready: the review is ready to inspect. It does not mean the product is ready for production.

If generation fails, CLI 0.3.1 preserves error.details.actionId when supplied. Retrieve that action before requesting new work. After a timeout without an ID, list actions for the project; see recovery.

5. Close the gap and preserve the decision

Have the responsible person attach or identify the missing evidence. Record what changed, which revision it applies to, and who accepted it. Re-run the review with the updated facts under a new key. Prior action outputs remain records of the earlier request.

Depending on the gap, request a DFM review, test plan, quality plan or compliance plan. These prepare work; the responsible engineer, manufacturer or lab still supplies the actual result.

For quote preparation, continue with intent and factory selection. Carry the reviewed requirements into the supported RFQ fields. A readiness review does not automatically filter the supplier directory or update an existing delivery draft.