spec-plan

spec-plan — spec → ordered build plan (class R, dry, no mutation)

Transform a structured project-spec (the project-spec model, §13.2) into the ordered sequence of offline operations that tia-scaffold would execute — without touching the project. This is the bridge between spec-validate (is the spec legal?) and tia-scaffold (build it): it shows the plan so a human can review it first.

It is class R. Both tools it uses — tia_spec_validate and tia_spec_plan — are pure: they run deterministically on the spec text and never call the serve API or open TIA. So this never mutates and never crosses a gate.

One optional step comes after the plan (step 4, Impact on the open project): with a project already open it reads, through serve, how the existing objects the plan would write to are cross-referenced. It is only a read, it never changes the plan and the plan never waits for it.

Errors and reporting

• Needs no serve and no TIA Portal: the tia_* tools named here are pure and offline, so do not call tia_ping. If they are not in the tool list, say so and use the fallback this skill names, or stop.
• Report the tool's answer as returned (violations, error, kind, hint) and state what was done and what was not. Never fix the input silently, never retry with changed input to get past a failure, and never report success after an error.
• The first bullet covers tia_spec_validate and tia_spec_plan. The optional Impact on the open project step (step 4) is the only part that reads through serve: only there call tia_ping, and only after the plan is presented. If it cannot run or fails (serve unreachable or not activated, no project open, tia_crossrefs or a read tool missing, a tool error), say impact not read with the reason (quote error, kind and hint verbatim for a tool error) and keep the plan as the answer. Never block or withdraw the plan on it, and never retry with changed arguments beyond the repeats step 4 names.
• On the reads of step 4, status:"running" + jobId (only tia_crossrefs answers it) and kind:"busy" are not failures and are handled differently. status:"running" + jobId identifies THIS request: poll tia_job_status {jobId} until the final result and never repeat the call; after a timeout, check the state before repeating anything. kind:"busy" means another job holds the serve and THIS request did not run: wait for that job with tia_job_status {jobId}, taking the jobId from details.jobId, never use that job's result for this read, then repeat the same read once with unchanged arguments; if it answers busy again, say impact not read with the reason.
• Also on the reads of step 4: a 409 cursor_stale, or coverage counts that differ between pages, restarts that object's page walk from the first page, once for each, and a page that arrives with an omission marker is repeated with a smaller limit, at most three times; step 4 says how. A read that cannot be completed is reported as impact not complete with the reason, never as an absence of impact.