Formalize

Formalize the Markdown roadmap

Treat blueprint/roadmap/**/*.md as the sole durable work graph. Resolve the absolute installed plugin root and run commands through the invocation contract in the CLI reference, from the Lean project. <PROJECT> is the absolute path of the checkout being edited; for a subagent, that is its own worktree. Start by running autoform work list <PROJECT> --lean-root <PROJECT> --json and inspect a selected leaf with autoform work context <NODE> <PROJECT> --lean-root <PROJECT> --json. The returned phase is derived from typed dependencies and verified assertions; never author ready, running, retrying, failed, or blocked scheduler states. If work list refuses because unfinished leaves lack article_id, add the IDs planned by autoform migrate article-ids <PROJECT>/blueprint --json to those articles' frontmatter, validate, and commit that change before claiming anything.

For a direct formalization request, use a compatible native persistent Goal when available and complete one useful frontier pass. Native subagents may work independent leaves in separate Git worktrees, but no custom scheduler or provider adapter is part of the protocol. The lead's branch is the shared branch that results integrate into; a leaf the lead takes itself is also worked in a worktree, so nothing reaches that branch before its default build passes. Before dispatching, commit the roadmap state the frontier was read from and base each worktree on that commit, not on the remote's default branch (Claude Code's agent isolation does so only with worktree.baseRef: head). Give each subagent the claim_target, phase, article_revision, open_statements, assumes, and revision it is dispatched for. A new worktree has no .lake: in a Mathlib project, run lake exe cache get there under the lake-build claim before its first build or Lean tool call.

Give every concurrent agent and subagent its own worker ID, such as its host and worktree name, and pass it as --worker-id on every claim command. Never reuse the lead's, because a board accepts a second acquire from the same owner, and do not rely on exporting AUTOFORM_WORKER_ID once: a later tool call can start from a profile that sets a shared value. Run claim commands from the project worktree so every worker uses its origin board, or pass the same --repo everywhere when it has none. Claims write refs to that board's remote, which is outward-facing: make sure the request covers it before the first claim.

Before editing, acquire the exact claim_target returned by work context. A failed acquire or renewal means ownership is unproven: stop writing. Leases expire after 25 minutes, so run autoform claim renew about every five minutes and immediately before integrating; renew, not acquire, is the check that a claim is still held. Take the lake-build resource claim only around a Lake build: if it is refused, wait and retry rather than abandoning the leaf, renew it during a long build, and release it as soon as the build ends.

After acquiring the claim, bring the worktree up to date with the shared branch and reload work context. Before editing, require the same phase, blockers, dependencies, article_revision, open_statements, assumes, and revision as the first read and, for a subagent, the same phase, article_revision, open_statements, assumes, and revision it was dispatched with. Unrelated parallel articles may legitimately change the graph-wide source revision.

Read the complete article, cited sources, dependency articles, and existing Lean target. Preserve the exact mathematical statement. Work only on the selected phase: do not modify another article or its Lean declarations, or weaken a public statement. The one exception is revising a declaration other articles' Lean uses: start from autoform work impact and make only the edits the revision contract requires, under the claims it requires. A work item flagged revision, whose article records statement: retracted, is such a revision; restating it replaces statement: retracted with statement: formalized. Never add a new use of a deprecated declaration. Search the pinned Mathlib checkout before adding helpers, and use the shared Lean LSP and REPL with <PROJECT> as the project path. Finish with the focused Lake target. Declare the result in a module the library root imports, or that the lakefile's globs cover, because the default build is the only one CI compiles and audits. Check the recorded declaration with #print axioms; do not accept sorry, new axioms, unsafe shortcuts, a weaker theorem, unused hypotheses, or an unrelated declaration, except as the open-statement policy below allows.

roadmap/README.md sets the project's policy. Under the default strict policy, project CI rejects sorry: the statement phase writes the declaration and, for a theorem, the complete proof, which is why work list offers the phase only once the proof prerequisites are proved. Under open_statements: allowed, the statement phase of a theorem writes the faithful statement with a proof body of exactly sorry and records statement: formalized, or writes the full proof and, on acceptance, records both assertions. That sorry is the declaration's whole body: never part of its type, a helper, a definition, or a where clause, and never one case of a recursive proof, which Lean can compile into auxiliaries such as _f that CI rejects. A definition is never left open: its body is its proof, so work list offers its statement phase only once its proof prerequisites are stated. In both policies the proof phase completes the proof of an already recorded statement without changing that statement.

Under the open policy a proof may use the open statements its Markdown dependencies reach: each open dependency with whatever its statement prerequisites reach, and everything a proved dependency reaches, but not an open dependency's proof prerequisites. autoform work assumptions --json lists the exact allowed_open_declarations. The article then shows as conditionally proved, and #print axioms lists the sorryAx it inherits without saying from where. Before landing, record proof: formalized in the worktree (until then the audit treats the article as open), reproduce the CI audit as the open statements reference shows, and require a conditional or sorry-free line for each recorded declaration and a passing summary. An open statement the Markdown does not declare as a dependency fails CI: send the missing dependency to Roadmap or stop using it. Never describe a conditional proof as complete, fully proved, or sorry-free.