[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71DMRX8A7CPV33EBQA473PV":3,"skill-same:01M71DMRX8A7CPV33EBQA473PV":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":56},"01M71DMRX8A7CPV33EBQA473PV","mm-build",null,"Activates Builder Mode for a journey and loads project context\u002Fdocs","mirror-mind-ai\u002Fmirror","mirror-mind-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F284655986?v=4","01M71DK28AKP6F5W1QCCBXN1W2","01M71DK29N7M7PSY7645ZQZ2B3",21,"MIT","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fmm-build\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30],"mm","mm build","build","builder","project","mode","journey","context","for","true","loads","project context","docs","2026-11-10 10:12:30",false,"---\nname: \"mm-build\"\ndescription: Activates Builder Mode for a journey and loads project context\u002Fdocs\nuser-invocable: true\n---\n\n# Builder Mode\n\nActivates Builder Mode for a specific journey. Loads identity context and project docs.\n\n## Usage\n\nPi:\n\n```\n\u002Fmm-build \u003Cjourney-slug>\n```\n\nCodex:\n\n```\n$mm-build \u003Cjourney-slug>\n```\n\nClaude Code:\n\n```\n\u002Fmm:build \u003Cjourney-slug>\n```\n\n---\n\n# Base Builder Mode Behavior\n\nThis is the default behavior for every journey, including journeys that have not\nadopted Ariad or any Builder method.\n\n## 1. Load Context (DB)\n\n```bash\nmirror build load \u003Cslug>\n```\n\nThe command:\n\n- Activates `■ Builder Mode` in the operating-mode lifecycle\n- Renders the Mode Transition Surface (`■ BUILDER MODE ACTIVE`)\n- Prints identity context (soul + ego + user + journey, persona=engineer)\n- Prints relevant memories\n- Starts a new database conversation session\n- Emits `project_path=\u003Cpath>` as the last output line\n\n## 1.1 Transition Surface\n\nRender the `build load` transition surface visibly before continuing with project\ndoc loading or substantive Builder work.\n\nFor journeys without adopted Ariad, preserve original Builder behavior:\n\n- load context;\n- read project docs;\n- stop at the Builder Activation Boundary;\n- ask what work should be done next.\n\nDo not render Ariad surfaces, Ariad lifecycle suggestions, roadmap snapshot,\npull candidates, cursor state, or checkpoint language for journeys that have not\nadopted Ariad.\n\nFor Ariad-adopted journeys, see **Ariad Runtime Behavior** below.\n\nBuilder Mode surface should orient the user around:\n\n- active journey\n- journey path\u002Fstage, when present\n- project path, when present\n- compact briefing\u002Fsynthesis\n- boundary: `Builder executes commitment.`\n\n## 1.2 Journey Binding\n\nEvery `build` command after `build load` carries `--journey \u003Cslug>`. The slug\nis the journey this session's `build load` activated, and its `■ BUILDER MODE\nACTIVE` surface names it. For a journey the Navigator names explicitly, pass\nthat slug instead.\n\nThe runtime never guesses the journey. Without `--journey`, a command binds\nonly to a session in Builder Mode named with `--session-id` or\n`MIRROR_SESSION_ID`. An agent shell names none, so the command refuses with\n`requires a journey`. A guessed journey once moved other journeys' cursors and\nwrote files into other projects.\n\nIf that refusal appears and this session's slug is no longer in view, ask the\nNavigator. Do not take the slug from `mode status`, the status line, or any\nother database-wide state. They can show another window's journey.\n\n## 2. Read Project Docs\n\nParse `project_path` from the last output line above. If `project_path` is not\nset, skip this step and proceed — the journey has no associated project yet.\n\nUse file tools to load project documentation. Prefer the project's actual\ndocumentation structure over any fixed scaffold.\n\n### Always read when present\n\n- `\u003Cproject_path>\u002FREADME.md` — public overview, setup, and usage\n- `\u003Cproject_path>\u002FREFERENCE.md` — detailed operational reference\n- `\u003Cproject_path>\u002FCLAUDE.md` — project-specific operating instructions\n- `\u003Cproject_path>\u002Fdocs\u002Findex.md` — documentation map\n\n### Discover available docs\n\nRun:\n\n```bash\nfind \u003Cproject_path>\u002Fdocs -maxdepth 3 -type f -name '*.md' | sort\n```\n\nThen read the docs relevant to the current task.\n\nFor Mirror Mind, the primary docs are:\n\n- `\u003Cproject_path>\u002Fdocs\u002Fgetting-started.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Fbriefing.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Fdecisions.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproduct\u002Fspecs\u002Fruntime-interface\u002Findex.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Froadmap\u002Findex.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fprocess\u002Fdevelopment-guide.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fprocess\u002Fworklog.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproduct\u002Fprinciples.md`\n\nWhen working inside a CV\u002FDelivery Story\u002FUser Story\u002FTechnical Story, also read the relevant:\n\n- `index.md`\n- `plan.md`\n- `test-guide.md`\n- `refactoring.md`, if present\n\n## 3. Builder Activation Boundary\n\nActivating Builder Mode or loading a journey is context setup only. After loading\nthe context and required docs, stop and ask what work should be done next.\n\nDo not edit files, create tests, run implementation, start TDD, or mutate project\nstate until the user gives an explicit implementation or documentation\ninstruction, such as `implement`, `fix`, `edit`, `create`, `run tests`, or names a\nspecific story to execute.\n\nContext activation is not execution consent.\n\n## 4. Work In Builder Mode\n\nOnce the user explicitly authorizes work:\n\n- Work from `project_path` — read, edit, and create project files normally\n- Keep project docs updated as the code evolves\n- Commit at the end of each session with a descriptive English commit message\n\n## 5. Project Docs Maintenance\n\nFollow the project's existing documentation structure. Do not create a generic\ndocs scaffold unless the user explicitly asks for one.\n\n**When to update docs:**\n\n- `README.md`: public positioning, setup, stack, or usage changes\n- `REFERENCE.md`: CLI behavior, configuration, runtime contracts, or operational details change\n- `docs\u002Fproject\u002Fbriefing.md`: stable architectural premises change\n- `docs\u002Fproject\u002Fdecisions.md`: an incremental design decision is made\n- `docs\u002Fproduct\u002Fspecs\u002Fruntime-interface\u002Findex.md`: runtime lifecycle, hooks, skills, or extension contracts change\n- `docs\u002Fproject\u002Froadmap\u002F`: CV\u002FDelivery Story\u002FUser Story\u002FTechnical Story status, plans, or verification guides change\n- `docs\u002Fprocess\u002Fworklog.md`: a meaningful milestone is completed\n- `docs\u002Fproduct\u002Fprinciples.md`: product, code, testing, or process principles change\n\n## 6. Configure `project_path`\n\nIf the journey does not yet have an associated project:\n\n```bash\nmirror journey set-path \u003Cslug> \u002Fpath\u002Fto\u002Fproject\n```\n\n## 7. Finalize Session\n\nWhen the user says \"End the session\":\n\n```bash\nmirror mirror log \"SESSION_SUMMARY\"\n```\n\n---\n\n# Adopted Method Behavior\n\nA journey may adopt a Builder method. Method-specific behavior applies only when\nthat method has been adopted for the active journey.\n\nCurrently implemented method-specific runtime: **Ariad**.\n\nFor journeys without adopted Ariad:\n\n- preserve Base Builder Mode behavior;\n- do not render Ariad surfaces;\n- do not route roadmap, pull, prepare, template, cursor, or lifecycle requests to Ariad commands;\n- if the user asks for Ariad behavior, explain that Ariad must be adopted first.\n\n## Inspect Builder Method\n\nWhen the user asks which Builder method governs the active journey, inspect the\ncurrent Builder method state:\n\n```bash\nmirror build inspect-method --journey \u003Cslug>\n```\n\nRender the command output visibly. If no Builder journey has been loaded in this\nsession, do not run the command: say so plainly and ask the user to activate or\nname a journey. If the journey has not\nadopted a Builder method yet, say so plainly. Do not infer that Ariad governs the\njourney just because Ariad is available.\n\nWhen the user asks what Ariad is as a Builder method, inspect the built-in method\ndefaults:\n\n```bash\nmirror build inspect-method ariad\n```\n\nThis is read-only inspection.\n\n## Adopt Ariad\n\nWhen the user explicitly asks to adopt Ariad for the active journey, run:\n\n```bash\nmirror build adopt --journey \u003Cslug> --method ariad\n```\n\nRender the adoption report visibly. This mutates Builder method state only. It\nmust not generate templates, create a delivery cursor, execute lifecycle work,\nchange story status, commit, push, or release.\n\n---\n\n# Ariad Runtime Behavior\n\nThis section applies **only when the active journey has adopted Ariad**\n(`adopted_method == ariad`).\n\n## Deterministic Ariad Surface Transport Protocol\n\nThis is a transport invariant for **all** Ariad commands and lifecycle phases,\nnot a phase-specific instruction. In the Ariad method DSL, surfaces are runtime\nartifacts with `transport=verbatim`, `marker_protocol=ariad_compact`, and\n`interpretation_policy=after_block_only`.\n\nAriad runtime commands emit deterministic surfaces wrapped as:\n\n```text\n\u003C\u003C\u003CARIAD:\u003CSURFACE_ID>>>\n...\n\u003C\u003C\u003CEND:\u003CSURFACE_ID>>>\n```\n\nFor any command output that contains one or more Ariad surface blocks, the final\nassistant response must return **every marked block** from stdout verbatim before\nany commentary. This is a hard rendering requirement, not optional tool-output\nevidence. Do not summarize, translate, reorder, trim, rewrap, re-indent,\nreformat, or mix prose inside a wrapped surface. Do not replace a surface with a\nconversational summary, even when the user phrase is short (for example,\n`validated`, `approved`, `ok`, or `continue`). If you catch yourself summarizing\na marked Ariad surface, stop and re-render the complete marked block before any\ninterpretation.\n\nIf multiple Ariad surface blocks are emitted, return all of them in the same\norder. After the complete surface block(s), add a conversational interpretation\nfor the Navigator. This interpretation should explain what happened, what it\nmeans, what is blocked or allowed now, and what the next Ariad step is. It may be\ncomplete and helpful, not merely a one-line summary, but it must stay outside the\nsurface block and must not contradict the runtime boundary.\n\nUse this pattern:\n\n```text\n\u003C\u003C\u003CARIAD:\u003CSURFACE_ID>>>\n...\n\u003C\u003C\u003CEND:\u003CSURFACE_ID>>>\n\nWhat happened:\n...\n\nNext step:\n...\n```\n\nA refused lifecycle command renders `CHECKPOINT_REFUSED`. Return it verbatim like\nany other surface. It shows the stage the cursor actually holds and the true reason,\nand nothing changed: the refusal comes before any write. Read the reason before\nacting. An already-complete step needs no rerun, a pending confirmation needs the\nNavigator's answer, a step not reached needs the step before it, and missing\nevidence needs the evidence the reason names. A failure that is not a refusal\nprints a plain `Error:` line instead and makes no claim about what changed: run\n`build show` to see where the cursor stands before trying again.\n\nIf a marked block was lost before it reached the Navigator (output filtered,\ntruncated, or never rendered), say which surface was lost and run `build show`, as\ndescribed in **Show The Active Checkpoint**. Return its `ACTIVE_CHECKPOINT` block\nverbatim. Never substitute another command's surface, such as `check-implementation`,\nas evidence of where the cursor stands.\n\n### Paths on Ariad surfaces\n\nA card prints a path inside the project relative to the journey's `project_path`,\nfrom the `project_path=` line `build load` prints. Open it by joining the two, never by joining it\nto the working directory, which can belong to another repository. A card that\nreports a file written or left in place names its project folder and journey on a\n`project:` row. If that row names a project or journey other than the one this\nsession loaded, tell the Navigator before touching the files. Plan prints its files'\nabsolute paths as `*_path=` lines below its surface. They are not part of the\nsurface: use them as printed, and do not render them.\n\n### Statuses on Ariad surfaces\n\nA row that names a roadmap package states its status as the first clause of the\npackage's `**Status:**` line, links reduced to their labels, cut to fit the row. The\nrest of the line is in the package the row names; read it there when you need more\nthan the status, such as why a package is Blocked.\n\n## Ariad Activation Surfaces\n\nFor Ariad-adopted journeys whose delivery cursor has no active item,\n`build load` emits:\n\n- `PROJECT POSITION`\n- `■ BUILDER ORIENTATION`\n\nFor Ariad-adopted journeys with no delivery cursor yet, or with an active item\nor a pending confirmation, `build load` emits:\n\n- `■ BUILDER RESUME`\n\nEvery position and next pull on these surfaces is the journey's own, derived\nfrom its delivery cursor. With an active item, the position is the Capability\nValue the item belongs to, and any recommended pull is chosen inside it. Without\none, the surfaces read `no item pulled yet`, list `project-wide candidates`,\nrecommend nothing, and give the literal `pull explicitly:` command. Never present\na candidate from the project-wide list as this journey's recommendation.\n\nThese surfaces are mandatory activation output. The final response to the user\nmust include the wrapped Ariad surface blocks verbatim from the command output.\nIf the command output contains `\u003C\u003C\u003CARIAD:BUILDER_RESUME>>>`,\n`\u003C\u003C\u003CARIAD:PROJECT_POSITION>>>`, or `\u003C\u003C\u003CARIAD:BUILDER_ORIENTATION>>>`, the\nresponse is invalid unless the visible reply also contains every complete\nmatching begin\u002Fend block in stdout order.\n\nAfter rendering these surfaces, do not ask a generic question such as \"inspeção\nruntime, planejamento de Delivery, ou exploração?\" and do not add a third\nruntime-inspection option unless the surface itself recommends it. For an Ariad\njourney with no active item, ask only which item the Navigator wants to pull,\nfrom the project-wide list and without ranking it, or whether to inspect the\nroadmap further, after the verbatim blocks.\n\nFor an Ariad journey with an active item, the resume's `allowed next actions` are\nthe steps the cursor accepts next, the recommended one first; `build show` prints\nthe same list. Offer the step the list names, and no lifecycle step it does not.\nOffering is not doing: the Builder Activation Boundary holds, and no step runs\nbefore the Navigator says so. Each step routes to a section of this skill, or in\nDelivery Story flow to its Delivery Story command:\n\n- `answer_pending_confirmation`: ask the Navigator the question the `pending\n  confirmation` row names. Never answer it.\n- `prepare_active_item`: Prepare, `build prepare-item`.\n- `expand_active_item`: Expand was blocked. After the Navigator fixes what\n  `EXPAND_BLOCKED` named, pull the Delivery Story again.\n- `plan_active_item`: Plan Ariad Work.\n- `implement_active_item`: the implementation guard, then the approved Plan.\n- `validate_active_item`: Validate Ariad Work.\n- `review_active_item_debt`: Review Ariad Debt.\n- `check_active_item_coherence`: Check Ariad Coherence.\n- `close_active_item`: Close Ariad Done.\n- `pull_candidate_if_known`: the item is closed, or none is pulled. Pull the item\n  the Navigator chooses, as Pull And Prepare Ariad Work describes.\n- `inspect_roadmap`: Inspect Roadmap And Pull Candidates.\n- `inspect_method`: Inspect Builder Method.\n- `sync_cursor`: Sync Delivery Cursor.\n- `adopt_method`: Adopt Ariad.\n\nA list of only `inspect_roadmap` and `inspect_method`, on an item that is open,\nmeans the cursor holds a position Ariad does not know. Say so, and offer\n`sync-cursor`, then Pull. `sync-cursor` drops the item and any pending question,\nand returns the cadence to `stepwise`.\n\n## Compose Refinement Work\n\n### The Refinement authority\n\nRefinement Work lives in project files, at this exact path beneath the trusted\n`project_path`:\n\n```text\ndocs\u002Fproject\u002Frefinement\u002Findex.md\n```\n\nThe root index is the sole authority for focus, ordering, and current RS\u002FCR\nstatus; linked documents own narrative, plans, evidence, and outcomes. Read the\nproject's own convention from the index before acting.\n\n**There is no second store.** CV22.DS10.TS4 retired the compatibility-only\nSQLite Workbench and its twenty commands; the front door answers each of them\nwith its cutoff. If the index does not exist, the project has not started\nRefinement Work — say so and offer to create the index. Never inspect legacy\nrows, never fall back to SQLite when a file-first operation is unclear, and\nnever treat an absent index as a different kind of authority.\n\n### File-first path\n\nWhen the Navigator asks to inspect, show, or orient to Refinement Work, read the\ncanonical index and the linked documents needed to explain the current focus.\nRender one compact, agent-composed `Refinement Workbench` view with these facts in\nthis order:\n\n1. canonical project-relative index path;\n2. focused RS and CR, or explicit `none` values;\n3. every RS with its canonical status;\n4. open CRs in canonical order with ID, RS, title, status, and canonical Driver\n   and Delivery details when assigned;\n5. terminal CR history after open work, preserving canonical Driver and Delivery\n   provenance when present;\n6. the next safe action for the focused item, grounded in its canonical status\n   and linked plan; and\n7. a boundary stating that inspection selected, changed, and executed nothing.\n\nUse `▸` to distinguish focused items. Preserve index ordering exactly. Omit an\nempty section cleanly or label it `none`; do not invent content. The root index\nwins whenever linked narrative disagrees about focus or status. Name the source\npath visibly and state that SQLite was not consulted. A representative shape is:\n\n```text\nRefinement Workbench\n\nsource\n\u003Ccanonical project-relative index path>\n\nCURRENT FOCUS\n\u003Cfocused RS or none>\n▸ \u003Cfocused CR or none>\n\nREFINEMENT STORIES\n\u003CRS rows in canonical order>\n\nOPEN CHANGE REQUESTS\n\u003Cnon-terminal CR rows in canonical order>\n  Driver: \u003Ccanonical human> · Delivery: \u003Ccanonical PR or branch>  # only when assigned\n\nTERMINAL HISTORY\n\u003Cterminal CR rows after open work, or none>\n  Driver: \u003Ccanonical human> · Delivery: \u003Ccanonical PR or branch>  # only when present\n\nNEXT SAFE ACTION\n\u003Cone grounded next action>\n\nBOUNDARY\nRead-only inspection. No work was selected, changed, or executed.\nSQLite was not consulted.\n```\n\nThis is a presentation contract for the agent reading project documents, not a\nruntime-generated deterministic Ariad surface. Do not wrap it in\n`\u003C\u003C\u003CARIAD:...>>>`, add a Markdown parser, or call legacy Workbench commands to\nproduce it. If the canonical index is unreadable or structurally ambiguous,\nreport the practical defect and stop instead of silently falling back to SQLite.\nRead-only intent stays read-only: recommend a concrete correction, but do not\nmutate files.\n\nTreat Driver and Delivery as canonical project facts, not runtime discoveries.\nShow them only when the index row provides values other than its documented empty\nmarker. Never infer assignment from the current Git checkout, branch author,\nlatest committer, active journey, conversation, or SQLite state. Follow the\nproject's collaboration convention when changing status: if it requires Driver\nand Delivery before `in_progress`, `blocked`, or `validated`, stop for the missing\nNavigator decision rather than synthesizing either value. Reassignment and stale\nwork disposition are semantic decisions and always remain explicit.\n\n#### Collaborative file-first lifecycle\n\nRead and follow any collaboration protocol linked by the canonical index. When no\nmore specific project rule exists, use this route:\n\n- **Inspect before mutation.** Read the complete index and relevant linked\n  documents. Confirm focus, existing IDs, target RS, status, Driver, and Delivery.\n- **Capture without selecting.** Require a concrete title, problem, expected\n  behavior, and explicit RS target. If the layout has no unassigned CR location,\n  stop rather than inventing one. Allocate the next unused project-wide numeric\n  ID from the complete index, preserve three-digit formatting, create one evolving\n  CR document with `Problem`, `Expected Behavior`, `Impact`, `Plan Or Decision`,\n  `Evidence`, and `Outcome`, append a `captured`\u002Funassigned row, and preserve\n  `Current Focus` exactly.\n- **Select explicitly.** Update only `Current Focus`. Selection changes no status\n  and authorizes neither planning nor implementation.\n- **Plan before implementation.** Record scope, affected files, acceptance,\n  validation, exclusions, and authority boundaries. Move `captured` to `planned`\n  only after Navigator approval.\n- **Assign before starting.** Before `in_progress`, obtain explicit human Driver\n  and branch\u002FPR Delivery decisions, then update status and both fields atomically.\n  Replace a branch reference with the PR link after the PR opens.\n- **Evidence is not validation.** Record checks and isolated smoke evidence during\n  implementation, but require an explicit natural Navigator validation route and\n  acceptance before `validated`.\n- **Review before terminal closure.** Record proportionality\u002Fdebt findings. `done`\n  requires accepted validation and resolved debt action. `blocked`, `parked`,\n  `rejected`, and `promoted` require narrative reasons; `parked` also requires a\n  revisit trigger and `promoted` a Delivery target. Move terminal CRs below open\n  work, preserve Driver\u002FDelivery provenance, and clear focused CR state without\n  selecting the next item implicitly.\n- **Return a handoff.** Report RS\u002FCR, canonical status, Driver, Delivery, changed\n  files, checks, Navigator validation, limitations, unresolved decisions, and the\n  requested next action. A handoff never grants merge, publication, or release.\n- **Let Git expose concurrency.** Refresh against the approved base before final\n  handoff. Never overwrite, silently renumber, merge narratives, delete another\n  contributor's work, or use SQLite to resolve ID\u002Findex\u002Ffocus\u002Fstatus conflicts.\n  Stop for semantic conflict resolution.\n\nWhen the Navigator asks how to create, work on, or collaborate through\nRefinement Work, answer read-only and explain the complete contributor route. Do\nnot stop the explanation at terminal status: include the return handoff and how\nordinary Git conflicts protect concurrent ID, index, focus, status, assignment,\nand narrative edits. Name the linked project protocol as the durable authority.\n\nStatus remains document vocabulary, not an application state machine. Do not add\nID reservation, locks, watchers, heartbeats, stale-work automation, Markdown\nparsing, projection, synchronization, or custom Git commands without repeated\noperational evidence and separate Navigator approval.\n\nWhen the Navigator authorizes a mutable operation such as capture, select,\ncontinue, update, or implement, that request also authorizes structural repairs\nneeded to complete it without a second confirmation only when every repair is:\n\n- necessary for the requested operation;\n- deterministic from existing project evidence;\n- local to the involved Refinement documents;\n- non-destructive and reversible through Git;\n- meaning-preserving; and\n- free of unrequested status, priority, focus, identity, SQLite, configuration,\n  commit, push, publication, or release decisions.\n\nAfter completing the operation, explain in Navigator-facing project language\nwhat defect was found, what was repaired, and what was left unchanged. Do not\nlead with internal Mirror terms such as projection, artifact mismatch, or\nruntime coherence.\n\nStop only when repair would choose product meaning, delete content, resolve a\nconcurrent conflict, or expand the original request. In that case, explain the\npractical consequence, recommend the smallest safe solution, name the files it\nwould change, and ask for the missing decision. Never use legacy SQLite as a\nrecovery path.\n\nFollow the canonical file's status vocabulary and ID convention. Do not invent\nmissing narrative or an RS assignment. Do not treat journey-local UUIDs or\nlegacy display codes as project artifact identity. Git owns history, conflicts,\nand recovery; ordinary file work must not create an application-level Git\nprotocol.\n\n## Prepare Ariad Templates\n\nWhen the user asks to prepare Ariad templates or make the adopted journey\ndocumentation-ready, run:\n\n```bash\nmirror build prepare-templates --journey \u003Cslug> --method ariad\n```\n\nRender the report visibly. The operation may create missing method-declared\ntemplate files, but must preserve existing files and must not create a delivery\ncursor, execute lifecycle work, change story status, commit, push, or release.\n\n## Sync Delivery Cursor\n\nWhen the user asks to sync the initial Builder delivery cursor for an\nAriad-adopted journey, run:\n\n```bash\nmirror build sync-cursor --journey \u003Cslug> --method ariad\n```\n\nRender the cursor sync report visibly. This persists runtime resume state only.\nIt must not infer an active roadmap item, execute Pull\u002FPrepare\u002FPlan, change story\nstatus, commit, push, or release.\n\n## Inspect Roadmap And Pull Candidates\n\nWhen the user asks to see the roadmap, inspect the roadmap, show roadmap\ncandidates, see what can be pulled, choose the next story, or asks \"o que posso\npuxar agora?\", run:\n\n```bash\nmirror build pull-candidates --journey \u003Cslug> --method ariad\n```\n\nRender the configured Ariad surfaces visibly, currently `ROADMAP SNAPSHOT` and\n`■ Ariad Pull Candidates`. With an active item both are scoped to its Capability\nValue: `candidates in \u003CCV>`, a count of those outside, and a recommendation\ninside the CV (or `no remaining candidates in \u003CCV>`). Without one, the list is\n`project-wide candidates` and no pull is recommended. This is read-only: it must\nnot pull an item, update the cursor, execute lifecycle work, change story status,\ncommit, push, or release.\n\n## Show The Active Checkpoint\n\nWhen the user asks where the active item stands or asks to see the current checkpoint\nagain, or when a surface was lost, run:\n\n```bash\nmirror build show --journey \u003Cslug> --method ariad\n```\n\nReturn the `ACTIVE_CHECKPOINT` surface verbatim. It shows the stage, the cursor's\nposition, the cadence, the steps the cursor accepts next, as the resume lists them,\nand the story package's files: `index.md`, `plan.md`, and `test-guide.md` with\ntheir state, and the closure records, each present or missing. It does not replay the\noriginal checkpoint surface: that evidence lives in those records, so read the one the\nNavigator needs, such as `plan.md` before Plan approval. It is read-only and changes\nneither the cursor nor any file.\n\n## Pull And Prepare Ariad Work\n\nWhen the user asks to change testing\u002Fruntime cadence, use:\n\n```bash\nmirror build set-cadence --journey \u003Cslug> --method ariad --profile \u003Cstepwise|checkpoint|accelerated|autonomous>\n```\n\nUse `stepwise` for detailed dogfooding: Plan stops for approval unless the Navigator naturally asks the Driver to create and execute the active story Plan without another approval turn. Use `checkpoint` for normal Ariad cadence. Use `accelerated` when the Navigator trusts the Driver to complete the active story Plan and continue directly into local implementation; the runtime automatically records bounded story Plan authority and still stops at Navigator Validation. Use `autonomous` only with explicit Navigator limits, for example:\n\n```bash\nmirror build set-cadence --journey \u003Cslug> --method ariad \\\n  --profile autonomous \\\n  --limit \"stop before push or release\" \\\n  --limit \"stop on scope change\" \\\n  --limit \"stop on failing checks\"\n```\n\nThe Builder resume, `build show`, and the Builder orientation print the cadence\nprofile and, under `autonomous`, its limits. Read it there before Plan: under\n`accelerated`, Plan continues into implementation without a Navigator turn.\n\nHigher-autonomy cadence never grants permission to cross Navigator validation acceptance, debt decisions, unsafe operations, scope changes, push\u002Frelease, or Done\u002Fhistory boundaries. For an active User Story or Technical Story in `story_by_story`, `accelerated` satisfies the Plan approval gate through a complete, structurally matching, single-use receipt instead of pausing for another Navigator turn; Plan completeness and mismatch checks still apply. In current Ariad, Pull is the Navigator signal to Prepare; pulling a Delivery Story also expands it into implementable User\u002FTechnical Stories and stops for confirmation of the recommended next story.\n\nWhen the user asks to continue under the active cadence, use:\n\n```bash\nmirror build continue-lifecycle --journey \u003Cslug> --method ariad \\\n  --process \"\u003Cprocess alignment evidence>\" \\\n  --project \"\u003Cproject\u002Fdocs\u002Fartifacts alignment evidence>\" \\\n  --product \"\u003Cproduct behavior alignment evidence>\" \\\n  --history-action \"\u003Crequired to cross Done\u002Fhistory boundary>\" \\\n  --roadmap-update \"\u003Crequired to cross Done\u002Fhistory boundary>\" \\\n  --next-recommendation \"\u003Crequired to cross Done\u002Fhistory boundary>\"\n```\n\n`continue-lifecycle` may emit multiple Ariad surfaces; return every marked block verbatim in order. In `stepwise` cadence it must refuse automatic continuation. In higher-autonomy cadence it may continue only through bypassable soft stops and must still stop at hard gates when required evidence is missing.\n\nWhen the user asks to pull a roadmap item into active Ariad work, run the\ncontained Pull command with explicit item metadata:\n\n```bash\nmirror build pull-item --journey \u003Cslug> --method ariad \\\n  --item-code \u003Ccode> \\\n  --item-title \"\u003Ctitle>\" \\\n  --item-level \u003Cdelivery_story|user_story|technical_story> \\\n  --why-now \"\u003Cwhy this level now>\"\n```\n\nRender all emitted surfaces visibly. Pull may update runtime cursor active item\nand automatically run Prepare. If the pulled item is a Delivery Story, Pull also\nexpands it into implementable child stories and recommends the next\nUser\u002FTechnical Story to plan. Pull must not create a Plan, approve a checkpoint,\nimplement, validate, review, close, commit, push, or release.\n\nWhen the Pull card's source reads `not in the roadmap`, say so to the Navigator\nbefore planning: the code may be mistyped, or the roadmap behind.\n\nWhen the Navigator confirms the recommended child story after an Expand surface,\npull that child story explicitly with `--item-level user_story` or\n`--item-level technical_story` using the recommended code\u002Ftitle from the surface.\nThen plan that implementable story when requested.\n\nWhen the user asks to prepare the pulled item, run:\n\n```bash\nmirror build prepare-item --journey \u003Cslug> --method ariad\n```\n\nRender the Prepare report visibly. Prepare may update the runtime cursor last\ndelivery event, but must not create a Plan, approve a checkpoint, start\nimplementation, change story status, commit, push, or release.\n\n## Delivery Story Candidate Table Authoring Contract\n\nExpand resolves an already-authored Delivery Story package by its `index.md`\nheading code, never by folder name or arithmetic on code and title -- an\nauthored package can live under any folder a human chose. Once resolved,\nExpand reads its `## Candidate Stories` table, header-driven. The header must\ninclude these four column names (case-insensitive, any order, extra columns\nsuch as `Outcome` or `Risk` are fine):\n\n```text\n| Code | Story | Type | Status |\n```\n\nor the 5-column generated variant:\n\n```text\n| Code | Story | Type | Outcome | Status |\n```\n\nWhen authoring or reviewing a Delivery Story `index.md` by hand, use this exact\ngrammar (see `docs\u002Fproject\u002Froadmap\u002Ftemplates\u002Fdelivery-story-index.md`). If the\nNavigator proposes a different shape (for example `| Family | Scope | Type |\nRisk |`), flag the mismatch before Pull\u002FExpand runs so the table is\nExpand-compatible by construction.\n\nA pipe inside a cell is written `\\|`, as GFM writes it, and reads back as `|`;\nAriad escapes the pipes in any title it writes into a cell.\n\nIf Expand renders `\u003C\u003C\u003CARIAD:EXPAND_BLOCKED>>>` (the resolved package's table\ndoes not parse, two packages claim the same code, or a Delivery Story with no\npackage would need a story that an authored package already claims), return the\nsurface verbatim per the transport protocol, then explain what to fix: correct\nthe table header to the canonical grammar, resolve the duplicate heading, or\nauthor the Delivery Story's `index.md` with a canonical candidate table that\nlists the story already authored. Do not\nhand-edit the package's materialized children to work around a blocked Expand,\nand do not re-run Pull\u002FExpand until the Navigator has fixed the authored\ncontent.\n\n## Delivery Story Release Intent\n\nWhen the active Ariad item belongs to a Delivery Story and the Navigator\nexplicitly says the DS is expected to create a release boundary, has no release\nintent, or remains undecided, record only that planning state:\n\n```bash\nmirror build release-intent --journey \u003Cslug> --method ariad \\\n  --intent \u003Cplanned|none|undecided>\n```\n\nTo inspect without changing state, omit `--intent`. Return the `RELEASE_INTENT`\nsurface verbatim.\n\nMap only explicit meaning:\n\n- `planned` — the DS is expected to create a release boundary if completed\n  coherently;\n- `none` — the DS is explicitly not expected to create a release boundary;\n- `undecided` — the decision is intentionally unresolved and may be revisited.\n\nDo not infer intent from cadence, version changes, completed implementation,\nexisting tags, roadmap position, or a previous DS. Release intent belongs to the\nDelivery Story ancestor and is not authorization to commit, push, create a tag,\npromote stable, publish a release, or mutate a remote system. Those remain\nseparate gates.\n\n## Delivery Story Navigator Flow\n\nWhen the active Ariad work is a Delivery Story or the Navigator refers to the\ncurrent Delivery Story and says a natural-language equivalent of:\n\n- `quero seguir no nível da DS`\n- `seguir no nível da Delivery Story`\n- `use Delivery Story flow`\n- `não preciso validar cada US`\n- `aprove um plano geral da DS e eu valido no fim`\n\nrun:\n\n```bash\nmirror build set-flow-unit --journey \u003Cslug> --method ariad --unit delivery_story\n```\n\nReturn the `DELIVERY_STORY_SCOPE_CONFIRMATION` surface verbatim. Explain after\nthe surface that child User\u002FTechnical Stories remain traceable Driver work\npackages, and that choosing Delivery Story flow does not approve a Plan, start\nimplementation, validate, push, or release.\n\nThe scope confirmation is a Navigator stop. It asks whether the scope is right\nbefore any DS Plan exists. The runtime records the stop without enforcing it: the\ncursor holds `navigator_scope_confirmation` until the Plan replaces it, and\n`plan-delivery-story` does not refuse while it is pending, so the question stays\ntrue only if you wait for the answer. End the turn after the surface. Do not run\n`plan-delivery-story` in the same turn, even when the Navigator's request also\nasked for the Plan. Plan only on a later Navigator turn that confirms or corrects\nthe scope. Cadence and Plan preauthorization do not remove this stop.\n\nA Builder resume that shows `pending confirmation: navigator_scope_confirmation`\nis this same question, still open. Ask it again, or render it again with the\n`set-flow-unit --unit delivery_story` command above, and plan only on the\nNavigator's answer.\n\nA flow unit is chosen only at the Delivery Story's flow decision, after Prepare or\nExpand and before its Plan. Anywhere else `set-flow-unit --unit` refuses with one\n`Error: no flow unit was chosen: ...` line and changes nothing. Relay that reason to\nthe Navigator. Do not reset or re-pull to force the choice without their decision.\n\n`set-flow-unit` without `--unit` only inspects the current choice and renders\n`NAVIGATOR_FLOW_UNIT`.\n\nWhen the effective flow unit is `story_by_story`, preserve existing child-story\nPlan behavior. Do not silently use Delivery Story-level Plan unless the\nNavigator has selected `delivery_story` flow or explicitly asks to follow work at\nDelivery Story level.\n\n## Delivery Story Plan Ariad Work\n\nWhen the active Ariad work is a Delivery Story with\n`navigator_flow_unit=delivery_story` and the Navigator says a natural-language\nequivalent of:\n\n- `planeje a DS`\n- `planeje a Delivery Story`\n- `plan the Delivery Story`\n- `crie o plano geral da DS`\n\nrun:\n\n```bash\nmirror build plan-delivery-story --journey \u003Cslug> --method ariad \\\n  --objective \"\u003Caggregate Delivery Story objective>\" \\\n  --child \u003Cchild-work-item-code>\n```\n\nPass one `--child` argument for each known child User\u002FTechnical Story work\npackage. If child work packages are already present in the cursor, the command\nmay use them; otherwise include the known roadmap child codes. If the user names\na specific journey, pass `--journey \u003Cslug>`.\n\nReturn the `DELIVERY_STORY_PLAN_CHECKPOINT` surface verbatim. Interpret only\nafter the block. Explain that the DS-level Plan is pending approval and that no\nimplementation, validation, push, or release is authorized by planning alone.\n\n### Conditional Plan preauthorization\n\nUse conditional preauthorization only when the Navigator explicitly authorizes\none active Delivery Story by exact child identity and names the fixed next hard\nstop at Navigator Validation. Vague continuation, cadence selection, “faça tudo”,\n“não me pergunte nada”, or generic autonomy language never creates authority.\nDelivery Story preauthorization applies only to `delivery_story` flow. Exact\nUser Story and Technical Story preauthorization is handled separately under\n`story_by_story` flow below.\n\nFor an explicit matching request, include:\n\n```bash\nmirror build plan-delivery-story --journey \u003Cslug> --method ariad \\\n  --objective \"\u003Caggregate Delivery Story objective>\" \\\n  --child \u003Cevery exact child code> \\\n  --preauthorize-approval \\\n  --stop-after navigator_validation\n```\n\nReturn `DELIVERY_STORY_PLAN_CHECKPOINT`,\n`PLAN_PREAUTHORIZATION_RECORDED`, and artifact surfaces verbatim. The receipt is\nnot approval: complete the Driver-owned `plan.md` first. Required sections must\nexist and contain no empty, `Pending`, TODO\u002FTBD, or placeholder body. Never\nreplace an existing non-empty Plan with the runtime scaffold.\n\nIn the same assistant turn, after completing the Plan, consume the receipt with:\n\n```bash\nmirror build approve-delivery-story-plan --journey \u003Cslug> --method ariad \\\n  --use-preauthorization\n```\n\nOn exact match, return every approval\u002Fstart surface, implement only local approved\nwork, and stop at Navigator Validation. On `PLAN_PREAUTHORIZATION_MISMATCH`,\nreturn the bounded surface and stop at ordinary Plan approval. Never repair,\nexpand, reinterpret, or recreate authority silently. Child order is\npresentational, but addition or removal is a mismatch.\n\nCancel pending authority when the Navigator withdraws it:\n\n```bash\nmirror build cancel-delivery-story-plan-preauthorization --journey \u003Cslug> \\\n  --method ariad\n```\n\nCancellation preserves the ordinary Plan approval gate. Preauthorization never\ncrosses validation acceptance, debt, Done\u002Fhistory, commit, push, release, deploy,\npurchase, or another irreversible boundary.\n\nIf the Navigator asks to plan the Delivery Story before selecting\n`delivery_story` flow, first surface or request the flow-unit choice; do not\nsilently use DS-level Plan from the default `story_by_story` flow. Surfacing the\nchoice with `set-flow-unit --unit delivery_story` ends the turn at its scope\nconfirmation, as described in Delivery Story Navigator Flow; plan on the\nNavigator's next turn.\n\nWhen the Navigator approves a pending DS-level Plan with natural language such\nas `aprovo o plano da DS`, `plano da DS aprovado`, or `approve the Delivery\nStory plan`, run:\n\n```bash\nmirror build approve-delivery-story-plan --journey \u003Cslug> --method ariad\n```\n\nReturn every emitted Ariad surface verbatim, including\n`DELIVERY_STORY_PLAN_CHECKPOINT`, `ARTIFACTS_MATERIALIZED`, and\n`IMPLEMENTATION_STARTED` when present.\n\nPlan approval authorizes local implementation under the approved DS Plan. After\nrendering the approval surfaces, do **not** stop to ask for a separate\nimplementation command. Immediately begin implementing the approved plan: read\nthe generated `plan.md` \u002F `test-guide.md` artifacts and relevant code, edit local\nproject files, and run appropriate checks. Still stop before hard gates: unsafe\noperations, scope changes, debt decisions, push, release, deploy, purchase,\nexternally irreversible actions, and final Done\u002Fhistory boundaries remain\nexplicit Navigator authorization points.\n\n## Plan Ariad Work\n\nWhen the user asks to plan the pulled item, create a plan for the active item, or\nsays a natural-language equivalent such as `planeje o item puxado`, run:\n\n```bash\nmirror build plan-item --journey \u003Cslug> --method ariad\n```\n\nRender the Plan Checkpoint visibly, and name the plan in the reply by its\nproject-relative path: the card's `story package`, then `\u002Fplan.md`. The card holds no plan: it names the story files,\n`index.md`, `plan.md`, and `test-guide.md`, each with its state and the sections\nstill to author. The plan is read in `plan.md`. Right after `plan-item` that file\nis usually the scaffold, so there is no plan to present yet: present it after it\nis authored, by the sequence below. Keep runtime cursor fields compact; do not let\ntechnical metadata replace the plan itself.\n\nPlan may update runtime cursor checkpoint state and may create\u002Fupdate the\nPlan-stage story package (`index.md`, `plan.md`, and `test-guide.md`) only for an\nimplementable User Story or Technical Story. Delivery Stories are never planned\nas the implementable unit; they must expand first. Plan must not approve the\ncheckpoint, start implementation, change implementation files for the pulled\nitem, change story status, commit, push, or release.\n\n### Author the plan before asking for approval\n\nPlan writes `plan.md` as a scaffold: template sentences with the item's title\npasted in. It is not a plan. The Objective, Scope, Acceptance Behavior, and\nValidation Route are what the Navigator approves from: write them for this\nstory, in Navigator-facing language. The Non-Goals, Implementation Contract,\nStop Conditions, and Approval Gate may stand as written when they are true. Unless\nthe Plan checkpoint or `build show` names `index.md` authored, write its story\nstatement, Outcome, and Acceptance Behavior too: it may say scaffold, partly\nauthored, or incomplete.\n\nThe sequence:\n\n1. `plan-item`.\n2. Author `plan.md`, and `index.md` unless the Plan checkpoint or `build show`\n   names it authored.\n3. Run `build show` and return its `ACTIVE_CHECKPOINT` block. It must read\n   `✓ plan.md — authored`; if it does not, author what it names and run it again.\n4. Present the plan from `plan.md`, section by section: the Objective, Scope,\n   Non-Goals, Acceptance Behavior, and Validation Route as the file states them,\n   not paraphrased into claims the file does not make. Then ask for approval.\n5. On approval, `approve-plan`.\n\nThe runtime checks structure, not quality: one real line under a heading passes\nit. That check is a floor. The bar is a plan the Navigator can approve from.\n\n`approve-plan` refuses with `CHECKPOINT_REFUSED` while any section it requires is\nmissing, empty, pending, or still the scaffold's, and names each by its heading.\nA refusal means: author what it names, run `build show`, and present the plan\nagain. Do not run `approve-plan` again in the same turn as if the approval were\nstill standing: the Navigator approved a plan that did not exist yet.\n\n`done-item` refuses the same way while the story's `index.md` still says what\nExpand or Plan wrote (\"I want to \u003Ctitle>\"). Write the story it is before closing\nit.\n\n### Conditional story Plan preauthorization\n\nUse story-level conditional preauthorization for one active User Story or\nTechnical Story in `story_by_story` flow through either of two routes:\n\n- **natural explicit delegation in any cadence** — the Navigator asks the Driver\n  to create the active story Plan and execute it without another Plan approval\n  turn, for example `crie o plano e execute sem que eu precise autorizar`,\n  `faça o plano e implemente com preautorização concedida`, or an equivalent\n  natural phrase;\n- **accelerated cadence** — `plan-item` automatically records bounded story Plan\n  authority, so the Driver completes the Plan and continues without a Plan stop.\n\nThe Navigator does not need to recite story identity, sibling exclusions,\nfingerprint policy, mismatch behavior, or the Validation boundary. Ariad derives\nthose safeguards from the active cursor and method: exact active item and level,\n`story_by_story` flow, current generation, no sibling scope, complete Plan,\nsingle use, bounded mismatch fallback, and stop at Navigator Validation.\n\nVague continuation such as `continue`, an isolated `faça tudo`, or `não me\npergunte nada` does not create stepwise story authority. Selecting `accelerated`\nis itself the explicit cadence decision that authorizes Plan continuation for\nactive implementable stories. For natural explicit delegation, run:\n\n```bash\nmirror build plan-item --journey \u003Cslug> --method ariad \\\n  --preauthorize-approval \\\n  --stop-after navigator_validation\n```\n\nIn `accelerated` cadence, run ordinary `plan-item` without the explicit flag; the\nruntime automatically records bounded story Plan authority and emits the same\nreceipt surface. Do not pause for Navigator approval after either route.\n\nReturn `PLAN_CHECKPOINT`, `PLAN_PREAUTHORIZATION_RECORDED`, and artifact surfaces\nverbatim. Preserve existing `index.md`, `plan.md`, and `test-guide.md` bytes. The\nreceipt is not approval: the Driver-owned Plan must be authored, as in\n[Author the plan before asking for approval](#author-the-plan-before-asking-for-approval),\nbefore authority can be consumed. The Objective, Scope, Acceptance Behavior, and\nValidation Route must be written for this story, not the scaffold's sentences, and\nthe Non-Goals and Implementation Contract must not be empty. A plan that is not\nauthored returns `PLAN_PREAUTHORIZATION_MISMATCH` with reason `plan_incomplete` and\nthe sections still to author.\n\nIn the same assistant turn, after completing the exact story Plan, run:\n\n```bash\nmirror build approve-plan --journey \u003Cslug> --method ariad \\\n  --use-preauthorization\n```\n\nOn exact match, return every approval and `IMPLEMENTATION_STARTED` surface,\nimplement only the active story locally, and stop at Navigator Validation. On\n`PLAN_PREAUTHORIZATION_MISMATCH`, return the bounded surface and stop at ordinary\nPlan approval; never repair, reinterpret, or recreate authority silently.\n\nCancel pending story authority when the Navigator withdraws it:\n\n```bash\nmirror build cancel-plan-preauthorization --journey \u003Cslug> --method ariad\n```\n\nCancellation preserves the ordinary Plan gate. Story authority is private,\nsingle-use, cursor-generation-bound, and cannot authorize a sibling story,\nValidation acceptance, Debt Review, Done\u002Fhistory, commit, push, release, deploy,\npurchase, or another irreversible action.\n\nWhen the Navigator approves an ordinary Plan checkpoint, run:\n\n```bash\nmirror build approve-plan --journey \u003Cslug> --method ariad\n```\n\nIf the user asks to implement while the Plan checkpoint is pending, run the guard\nbefore doing any implementation work:\n\n```bash\nmirror build check-implementation --journey \u003Cslug> --method ariad\n```\n\nRender the deterministic `IMPLEMENTATION_GUARD` surface. If the guard reports\nthat Navigator approval is required, return the surface and stop. Do not mutate\nfiles.\n\n## Closure Records\n\n`validation.md`, `review.md`, `coherence.md`, and `done.md` are records\nthat Ariad seals: their last line is `\u003C!-- ariad-seal sha256:… -->`. A closure\ncommand rewrites a record only while its seal still matches. Anything else is\nleft exactly as it is, and the checkpoint says `preserved`.\n\n`preserved` is not an error. It means a person wrote or edited the file, and\ntheir version stands. The checkpoint's fields are in the surface you render, and\nthey were not written to the file.\n\n- Never delete, rewrite, or re-seal an authored record to make Ariad write it.\n- Never copy a seal line into a file.\n- If the Navigator wants Ariad's record in the file, ask how they want their\n  own notes kept.\n\n## Delivery Story Validation And Closure\n\nWhen the active Ariad work is a Delivery Story with\n`navigator_flow_unit=delivery_story` and an approved aggregate DS Plan, route\nnatural Navigator requests for aggregate DS closure through the Delivery Story\nruntime commands.\n\nFor natural validation requests such as `valide a DS`, `valide a Delivery\nStory`, or `validação da DS aceita`, run:\n\n```bash\nmirror build validate-delivery-story --journey \u003Cslug> --method ariad \\\n  --summary \"\u003Caggregate DS validation evidence>\" \\\n  --navigator-accepted\n```\n\nFor DS-level debt review requests, run:\n\n```bash\nmirror build review-delivery-story --journey \u003Cslug> --method ariad \\\n  --decision \u003Cno_action|defer|pay_now> \\\n  --summary \"\u003CDS-level debt review summary>\"\n```\n\nFor DS-level Done requests after Debt Review and Navigator closure confirmation,\nfirst align authored project state: mark the resolved Delivery Story package,\nevery known child package\u002Fcandidate row, and every canonical roadmap table row\nfor the DS as Done. Then run:\n\n```bash\nmirror build done-delivery-story --journey \u003Cslug> --method ariad \\\n  --summary \"\u003CDS-level done\u002Fhistory summary>\"\n```\n\nThe command runs an authored roadmap closure preflight before cursor or artifact\nmutation. If any DS package, known child package\u002Fcandidate row, or canonical\nroadmap row remains non-Done, the runtime refuses Done before cursor or artifact mutation and names project-relative files to align. The agent owns semantic\nMarkdown updates; the runtime verifies explicit status evidence and never invents\nproject meaning.\n\nDS-level Coherence is not a separate lifecycle stage before Done. It is checked\ninside Done only after the authored status preflight passes, so the final surface\ncan truthfully state that docs, roadmap, cursor, artifacts, and next-pull readiness\nremain consistent after closure.\n\nReturn every `DELIVERY_STORY_CLOSURE_CHECKPOINT` surface verbatim. Explain after\nthe block that child User\u002FTechnical Stories remain evidence units and that\npush\u002Frelease remain separate hard gates. Do not use these DS-level closure\ncommands when the effective flow unit is `story_by_story`; preserve existing\nchild-story lifecycle behavior in that mode.\n\n## Validate Ariad Work\n\nAfter implementation is complete and before moving to Debt Review or Done,\nrender the Validation checkpoint:\n\n```bash\nmirror build validate-item --journey \u003Cslug> --method ariad \\\n  --implementation-complete \\\n  --check \"\u003Cautomated check command or evidence>\" \\\n  --checks-status \u003Cpassed|failed|not_run> \\\n  --e2e-decision \u003Crequired|not_required|waived|skipped> \\\n  --e2e-evidence \"\u003CE2E evidence or waiver\u002Fskipped reason>\" \\\n  --navigator-route \"\u003CNavigator-visible validation route>\" \\\n  --navigator-accepted \\\n  --expected-observation \"\u003Cwhat the Navigator should observe>\" \\\n  --pass-condition \"\u003Cwhat counts as pass>\" \\\n  --fail-condition \"\u003Cwhat counts as fail>\"\n```\n\nIf the Navigator has already performed and accepted the validation route, also\npass `--navigator-accepted`. Providing a route is not the same as acceptance.\n\nRender the deterministic `VALIDATION_CHECKPOINT` surface. If required evidence\nis missing or Navigator validation has not been accepted, return the surface and\nstop; do not advance to Debt Review, Done, commit, push, or release.\n\n## Review Ariad Debt\n\nAfter Validation has passed and before moving to Done, render the Debt Review\ncheckpoint:\n\n```bash\nmirror build review-item --journey \u003Cslug> --method ariad \\\n  --debt \"\u003Cdebt finding, or No debt found>\" \\\n  --decision \u003Cpending|no_action|defer|pay_now> \\\n  --defer-reason \"\u003Crequired when decision=defer>\" \\\n  --revisit-trigger \"\u003Crequired when decision=defer>\"\n```\n\nRender the deterministic `DEBT_REVIEW_CHECKPOINT` surface. If the decision is\n`pending`, `defer` without a reason\u002Ftrigger, or `pay_now`, stop at the debt\ndecision checkpoint. `pay_now` must route through a future Refactor loop before\nDone. Do not advance to Done, commit, push, or release while the debt decision\nis unresolved.\n\n## Check Ariad Coherence\n\nAfter Debt Review is complete, verify Process, Project, and Product alignment:\n\n```bash\nmirror build coherence-item --journey \u003Cslug> --method ariad \\\n  --process \"\u003Cprocess alignment evidence>\" \\\n  --project \"\u003Cproject alignment evidence>\" \\\n  --product \"\u003Cproduct alignment evidence>\"\n```\n\nRender the `COHERENCE_CHECKPOINT` surface. If it reports `pending_coherence`,\ncorrect the missing evidence and rerun the same command. Reentry is valid only\nfor the exact `navigator_coherence` \u002F `last_delivery_event=coherence` state. It\nre-evaluates the evidence; it does not bypass Coherence. Unrelated pending\nconfirmations stay blocked, and `done-item` never consumes\n`navigator_coherence`.\n\n## Close Ariad Done\n\nAfter Coherence is complete and the Navigator confirms there is nothing else to\ndo in the story, render the Done checkpoint:\n\n```bash\nmirror build done-item --journey \u003Cslug> --method ariad \\\n  --history-action \"\u003Ccommit\u002Fhistory action taken or proposed>\" \\\n  --roadmap-update \"\u003Croadmap\u002Fstory package update>\" \\\n  --next-recommendation \"\u003Cnext Pull, parent collapse, or release boundary>\"\n```\n\nRender the deterministic `DONE_CHECKPOINT` surface. Done must name the history\naction, roadmap\u002Fstory package update, and next Ariad movement. Do not push or\nrelease unless the effective policy explicitly allows it.\n","# Builder Mode\n\nActivates Builder Mode for a specific journey. Loads identity context and project docs.\n\n## Usage\n\nPi:\n\n```\n\u002Fmm-build \u003Cjourney-slug>\n```\n\nCodex:\n\n```\n$mm-build \u003Cjourney-slug>\n```\n\nClaude Code:\n\n```\n\u002Fmm:build \u003Cjourney-slug>\n```\n\n---\n\n# Base Builder Mode Behavior\n\nThis is the default behavior for every journey, including journeys that have not\nadopted Ariad or any Builder method.\n\n## 1. Load Context (DB)\n\n```bash\nmirror build load \u003Cslug>\n```\n\nThe command:\n\n- Activates `■ Builder Mode` in the operating-mode lifecycle\n- Renders the Mode Transition Surface (`■ BUILDER MODE ACTIVE`)\n- Prints identity context (soul + ego + user + journey, persona=engineer)\n- Prints relevant memories\n- Starts a new database conversation session\n- Emits `project_path=\u003Cpath>` as the last output line\n\n## 1.1 Transition Surface\n\nRender the `build load` transition surface visibly before continuing with project\ndoc loading or substantive Builder work.\n\nFor journeys without adopted Ariad, preserve original Builder behavior:\n\n- load context;\n- read project docs;\n- stop at the Builder Activation Boundary;\n- ask what work should be done next.\n\nDo not render Ariad surfaces, Ariad lifecycle suggestions, roadmap snapshot,\npull candidates, cursor state, or checkpoint language for journeys that have not\nadopted Ariad.\n\nFor Ariad-adopted journeys, see **Ariad Runtime Behavior** below.\n\nBuilder Mode surface should orient the user around:\n\n- active journey\n- journey path\u002Fstage, when present\n- project path, when present\n- compact briefing\u002Fsynthesis\n- boundary: `Builder executes commitment.`\n\n## 1.2 Journey Binding\n\nEvery `build` command after `build load` carries `--journey \u003Cslug>`. The slug\nis the journey this session's `build load` activated, and its `■ BUILDER MODE\nACTIVE` surface names it. For a journey the Navigator names explicitly, pass\nthat slug instead.\n\nThe runtime never guesses the journey. Without `--journey`, a command binds\nonly to a session in Builder Mode named with `--session-id` or\n`MIRROR_SESSION_ID`. An agent shell names none, so the command refuses with\n`requires a journey`. A guessed journey once moved other journeys' cursors and\nwrote files into other projects.\n\nIf that refusal appears and this session's slug is no longer in view, ask the\nNavigator. Do not take the slug from `mode status`, the status line, or any\nother database-wide state. They can show another window's journey.\n\n## 2. Read Project Docs\n\nParse `project_path` from the last output line above. If `project_path` is not\nset, skip this step and proceed — the journey has no associated project yet.\n\nUse file tools to load project documentation. Prefer the project's actual\ndocumentation structure over any fixed scaffold.\n\n### Always read when present\n\n- `\u003Cproject_path>\u002FREADME.md` — public overview, setup, and usage\n- `\u003Cproject_path>\u002FREFERENCE.md` — detailed operational reference\n- `\u003Cproject_path>\u002FCLAUDE.md` — project-specific operating instructions\n- `\u003Cproject_path>\u002Fdocs\u002Findex.md` — documentation map\n\n### Discover available docs\n\nRun:\n\n```bash\nfind \u003Cproject_path>\u002Fdocs -maxdepth 3 -type f -name '*.md' | sort\n```\n\nThen read the docs relevant to the current task.\n\nFor Mirror Mind, the primary docs are:\n\n- `\u003Cproject_path>\u002Fdocs\u002Fgetting-started.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Fbriefing.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Fdecisions.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproduct\u002Fspecs\u002Fruntime-interface\u002Findex.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproject\u002Froadmap\u002Findex.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fprocess\u002Fdevelopment-guide.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fprocess\u002Fworklog.md`\n- `\u003Cproject_path>\u002Fdocs\u002Fproduct\u002Fprinciples.md`\n\nWhen working inside a CV\u002FDelivery Story\u002FUser Story\u002FTechnical Story, also read the relevant:\n\n- `index.md`\n- `plan.md`\n- `test-guide.md`\n- `refactoring.md`, if present\n\n## 3. Builder Activation Boundary\n\nActivating Builder Mode or loading a journey is context setup only. After loading\nthe context and required docs, stop and ask what work should be done next.\n\nDo not edit files, create tests, run implementation, start TDD, or mutate project\nstate until the user gives an explicit implementation or documentation\ninstruction, such as `implement`, `fix`, `edit`, `create`, `run tests`, or names a\nspecific story to execute.\n\nContext activation is not execution consent.\n\n## 4. Work In Builder Mode\n\nOnce the user explicitly authorizes work:\n\n- Work from `project_path` — read, edit, and create project files normally\n- Keep project docs updated as the code evolves\n- Commit at the end of each session with a descriptive English commit message\n\n## 5. Project Docs Maintenance\n\nFollow the project's existing documentation structure. Do not create a generic\ndocs scaffold unless the user explicitly asks for one.\n\n**When to update docs:**\n\n- `README.md`: public positioning, setup, stack, or usage changes\n- `REFERENCE.md`: CLI behavior, configuration, runtime contracts, or operational details change\n- `docs\u002Fproject\u002Fbriefing.md`: stable architectural premises change\n- `docs\u002Fproject\u002Fdecisions.md`: an incremental design decision is made\n- `docs\u002Fproduct\u002Fspecs\u002Fruntime-interface\u002Findex.md`: runtime lifecycle, hooks, skills, or extension contracts change\n- `docs\u002Fproject\u002Froadmap\u002F`: CV\u002FDelivery Story\u002FUser Story\u002FTechnical Story status, plans, or verification guides change\n- `docs\u002Fprocess\u002Fworklog.md`: a meaningful milestone is completed\n- `docs\u002Fproduct\u002Fprinciples.md`: product, code, testing, or process principles change\n\n## 6. Configure `project_path`\n\nIf the journey does not yet have an associated project:\n\n```bash\nmirror journey set-path \u003Cslug> \u002Fpath\u002Fto\u002Fproject\n```\n\n## 7. Finalize Session\n\nWhen the user says \"End the session\":\n\n```bash\nmirror mirror log \"SESSION_SUMMARY\"\n```\n\n---\n\n# Adopted Method Behavior\n\nA journey may adopt a Builder method. Method-specific behavior applies only when\nthat method has been adopted for the active journey.\n\nCurrently implemented method-specific runtime: **Ariad**.\n\nFor journeys without adopted Ariad:\n\n- preserve Base Builder Mode behavior;\n- do not render Ariad surfaces;\n- do not route roadmap, pull, prepare, template, cursor, or lifecycle requests to Ariad commands;\n- if the user asks for Ariad behavior, explain that Ariad must be adopted first.\n\n## Inspect Builder Method\n\nWhen the user asks which Builder method governs the active journey, inspect the\ncurrent Builder method state:\n\n```bash\nmirror build inspect-method --journey \u003Cslug>\n```\n\nRender the command output visibly. If no Builder journey has been loaded in this\nsession, do not run the command: say so plainly and ask the user to activate or\nname a journey. If the journey has not\nadopted a Builder method yet, say so plainly. Do not infer that Ariad governs the\njourney just because Ariad is available.\n\nWhen the user asks what Ariad is as a Builder method, inspect the built-in method\ndefaults:\n\n```bash\nmirror build inspect-method ariad\n```\n\nThis is read-only inspection.\n\n## Adopt Ariad\n\nWhen the user explicitly asks to adopt Ariad for the active journey, run:\n\n```bash\nmirror build adopt --journey \u003Cslug> --method ariad\n```\n\nRender the adoption report visibly. This mutates Builder method state only. It\nmust not generate templates, create a delivery cursor, execute lifecycle work,\nchange story status, commit, push, or release.\n\n---\n\n# Ariad Runtime Behavior\n\nThis section applies **only when the active journey has adopted Ariad**\n(`adopted_method == ariad`).\n\n## Deterministic Ariad Surface Transport Protocol\n\nThis is a transport invariant for **all** Ariad commands and lifecycle phases,\nnot a phase-specific instruction. In the Ariad method DSL, surfaces are runtime\nartifacts with `transport=verbatim`, `marker_protocol=ariad_compact`, and\n`interpretation_policy=after_block_only`.\n\nAriad runtime commands emit deterministic surfaces wrapped as:\n\n```text\n\u003C\u003C\u003CARIAD:\u003CSURFACE_ID>>>\n...\n\u003C\u003C\u003CEND:\u003CSURFACE_ID>>>\n```\n\nFor any command output that contains one or more Ariad surface blocks, the final\nassistant response must return **every marked block** from stdout verbatim before\nany commentary. This is a hard rendering requirement, not optional tool-output\nevidence. Do not summarize, translate, reorder, trim, rewrap, re-indent,\nreformat, or mix prose inside a wrapped surface. Do not replace a surface with a\nconversational summary, even when the user phrase is short (for example,\n`validated`, `approved`, `ok`, or `continue`). If you catch yourself summarizing\na marked Ariad surface, stop and re-render the complete marked block before any\ninterpretation.\n\nIf multiple Ariad surface blocks are emitted, return all of them in the same\norder. After the complete surface block(s), add a conversational interpretation\nfor the Navigator. This interpretation should explain what happened, what it\nmeans, what is blocked or allowed now, and what the next Ariad step is. It may be\ncomplete and helpful, not merely a one-line summary, but it must stay outside the\nsurface block and must not contradict the runtime boundary.\n\nUse this pattern:\n\n```text\n\u003C\u003C\u003CARIAD:\u003CSURFACE_ID>>>\n...\n\u003C\u003C\u003CEND:\u003CSURFACE_ID>>>\n\nWhat happened:\n...\n\nNext step:\n...\n```\n\nA refused lifecycle command renders `CHECKPOINT_REFUSED`. Return it verbatim like\nany other surface. It shows the stage the cursor actually holds and the true reason,\nand nothing changed: the refusal comes before any write. Read the reason before\nacting. An already-complete step needs no rerun, a pending confirmation needs the\nNavigator's answer, a step not reached needs the step before it, and missing\nevidence needs the evidence the reason names. A failure that is not a refusal\nprints a plain `Error:` line instead and makes no claim about what changed: run\n`build show` to see where the cursor stands before trying again.\n\nIf a marked block was lost before it reached the Navigator (output filtered,\ntruncated, or never rendered), say which surface was lost and run `build show`, as\ndescribed in **Show The Active Checkpoint**. Return its `ACTIVE_CHECKPOINT` block\nverbatim. Never substitute another command's surface, such as `check-implementation`,\nas evidence of where the cursor stands.\n\n### Paths on Ariad surfaces\n\nA card prints a path inside the project relative to the journey's `project_path`,\nfrom the `project_path=` line `build load` prints. Open it by joining the two, never by joining it\nto the working directory, which can belong to another repository. A card that\nreports a file written or left in place names its project folder and journey on a\n`project:` row. If that row names a project or journey other than the one this\nsession loaded, tell the Navigator before touching the files. Plan prints its files'\nabsolute paths as `*_path=` lines below its surface. They are not part of the\nsurface: use them as printed, and do not render them.\n\n### Statuses on Ariad surfaces\n\nA row that names a roadmap package states its status as the first clause of the\npackage's `**Status:**` line, links reduced to their labels, cut to fit the row. The\nrest of the line is in the package the row names; read it there when you need more\nthan the status, such as why a package is Blocked.\n\n## Ariad Activation Surfaces\n\nFor Ariad-adopted journeys whose delivery cursor has no active item,\n`build load` emits:\n\n- `PROJECT POSITION`\n- `■ BUILDER ORIENTATION`\n\nFor Ariad-adopted journeys with no delivery cursor yet, or with an active item\nor a pending confirmation, `build load` emits:\n\n- `■ BUILDER RESUME`\n\nEvery position and next pull on these surfaces is the journey's own, derived\nfrom its delivery cursor. With an active item, the position is the Capability\nValue the item belongs to, and any recommended pull is chosen inside it. Without\none, the surfaces read `no item pulled yet`, list `project-wide candidates`,\nrecommend nothing, and give the literal `pull explicitly:` command. Never present\na candidate from the project-wide list as this journey's recommendation.\n\nThese surfaces are mandatory activation output. The final response to the user\nmust include the wrapped Ariad surface blocks verbatim from the command output.\nIf the command output contains `\u003C\u003C\u003CARIAD:BUILDER_RESUME>>>`,\n`\u003C\u003C\u003CARIAD:PROJECT_POSITION>>>`, or `\u003C\u003C\u003CARIAD:BUILDER_ORIENTATION>>>`, the\nresponse is invalid unless the visible reply also contains every complete\nmatching begin\u002Fend block in stdout order.\n\nAfter rendering these surfaces, do not ask a generic question such as \"inspeção\nruntime, planejamento de Delivery, ou exploração?\" and do not add a third\nruntime-inspection option unless the surface itself recommends it. For an Ariad\njourney with no active item, ask only which item the Navigator wants to pull,\nfrom the project-wide list and without ranking it, or whether to inspect the\nroadmap further, after the verbatim blocks.\n\nFor an Ariad journey with an active item, the resume's `allowed next actions` are\nthe steps the cursor accepts next, the recommended one first; `build show` prints\nthe same list. Offer the step the list names, and no lifecycle step it does not.\nOffering is not doing: the Builder Activation Boundary holds, and no step runs\nbefore the Navigator says so. Each step routes to a section of this skill, or in\nDelivery Story flow to its Delivery Story command:\n\n- `answer_pending_confirmation`: ask the Navigator the question the `pending\n  confirmation` row names. Never answer it.\n- `prepare_active_item`: Prepare, `build prepare-item`.\n- `expand_active_item`: Expand was blocked. After the Navigator fixes what\n  `EXPAND_BLOCKED` named, pull the Delivery Story again.\n- `plan_active_item`: Plan Ariad Work.\n- `implement_active_item`: the implementation guard, then the approved Plan.\n- `validate_active_item`: Validate Ariad Work.\n- `review_active_item_debt`: Review Ariad Debt.\n- `check_active_item_coherence`: Check Ariad Coherence.\n- `close_active_item`: Close Ariad Done.\n- `pull_candidate_if_known`: the item is closed, or none is pulled. Pull the item\n  the Navigator chooses, as Pull And Prepare Ariad Work describes.\n- `inspect_roadmap`: Inspect Roadmap And Pull Candidates.\n- `inspect_method`: Inspect Builder Method.\n- `sync_cursor`: Sync Delivery Cursor.\n- `adopt_method`: Adopt Ariad.\n\nA list of only `inspect_roadmap` and `inspect_method`, on an item that is open,\nmeans the cursor holds a position Ariad does not know. Say so, and offer\n`sync-cursor`, then Pull. `sync-cursor` drops the item and any pending question,\nand returns the cadence to `stepwise`.\n\n## Compose Refinement Work\n\n### The Refinement authority\n\nRefinement Work lives in project files, at this exact path beneath the trusted\n`project_path`:\n\n```text\ndocs\u002Fproject\u002Frefinement\u002Findex.md\n```\n\nThe root index is the sole authority for focus, ordering, and current RS\u002FCR\nstatus; linked documents own narrative, plans, evidence, and outcomes. Read the\nproject's own convention from the index before acting.\n\n**There is no second store.** CV22.DS10.TS4 retired the compatibility-only\nSQLite Workbench and its twenty commands; the front door answers each of them\nwith its cutoff. If the index does not exist, the project has not started\nRefinement Work — say so and offer to create the index. Never inspect legacy\nrows, never fall back to SQLite when a file-first operation is unclear, and\nnever treat an absent index as a different kind of authority.\n\n### File-first path\n\nWhen the Navigator asks to inspect, show, or orient to Refinement Work, read the\ncanonical index and the linked documents needed to explain the current focus.\nRender one compact, agent-composed `Refinement Workbench` view with these facts in\nthis order:\n\n1. canonical project-relative index path;\n2. focused RS and CR, or explicit `none` values;\n3. every RS with its canonical status;\n4. open CRs in canonical order with ID, RS, title, status, and canonical Driver\n   and Delivery details when assigned;\n5. terminal CR history after open work, preserving canonical Driver and Delivery\n   provenance when present;\n6. the next safe action for the focused item, grounded in its canonical status\n   and linked plan; and\n7. a boundary stating that inspection selected, changed, and executed nothing.\n\nUse `▸` to distinguish focused items. Preserve index ordering exactly. Omit an\nempty section cleanly or label it `none`; do not invent content. The root index\nwins whenever linked narrative disagrees about focus or status. Name the source\npath visibly and state that SQLite was not consulted. A representative shape is:\n\n```text\nRefinement Workbench\n\nsource\n\u003Ccanonical project-relative index path>\n\nCURRENT FOCUS\n\u003Cfocused RS or none>\n▸ \u003Cfocused CR or none>\n\nREFINEMENT STORIES\n\u003CRS rows in canonical order>\n\nOPEN CHANGE REQUESTS\n\u003Cnon-terminal CR rows in canonical order>\n  Driver: \u003Ccanonical human> · Delivery: \u003Ccanonical PR or branch>  # only when assigned\n\nTERMINAL HISTORY\n\u003Cterminal CR rows after open work, or none>\n  Driver: \u003Ccanonical human> · Delivery: \u003Ccanonical PR or branch>  # only when present\n\nNEXT SAFE ACTION\n\u003Cone grounded next action>\n\nBOUNDARY\nRead-only inspection. No work was selected, changed, or executed.\nSQLite was not consulted.\n```\n\nThis is a presentation contract for the agent reading project documents, not a\nruntime-generated deterministic Ariad surface. Do not wrap it in\n`\u003C\u003C\u003CARIAD:...>>>`, add a Markdown parser, or call legacy Workbench commands to\nproduce it. If the canonical index is unreadable or structurally ambiguous,\nreport the practical defect and stop instead of silently falling back to SQLite.\nRead-only intent stays read-only: recommend a concrete correction, but do not\nmutate files.\n\nTreat Driver and Delivery as canonical project facts, not runtime discoveries.\nShow them only when the index row provides values other than its documented empty\nmarker. Never infer assignment from the current Git checkout, branch author,\nlatest committer, active journey, conversation, or SQLite state. Follow the\nproject's collaboration convention when changing status: if it requires Driver\nand Delivery before `in_progress`, `blocked`, or `validated`, stop for the missing\nNavigator decision rather than synthesizing either value. Reassignment and stale\nwork disposition are semantic decisions and always remain explicit.\n\n#### Collaborative file-first lifecycle\n\nRead and follow any collaboration protocol linked by the canonical index. When no\nmore specific project rule exists, use this route:\n\n- **Inspect before mutation.** Read the complete index and relevant linked\n  documents. Confirm focus, existing IDs, target RS, status, Driver, and Delivery.\n- **Capture without selecting.** Require a concrete title, problem, expected\n  behavior, and explicit RS target. If the layout has no unassigned CR location,\n  stop rather than inventing one. Allocate the next unused project-wide numeric\n  ID from the complete index, preserve three-digit formatting, create one evolving\n  CR document with `Problem`, `Expected Behavior`, `Impact`, `Plan Or Decision`,\n  `Evidence`, and `Outcome`, append a `captured`\u002Funassigned row, and preserve\n  `Current Focus` exactly.\n- **Select explicitly.** Update only `Current Focus`. Selection changes no status\n  and authorizes neither planning nor implementation.\n- **Plan before implementation.** Record scope, affected files, acceptance,\n  validation, exclusions, and authority boundaries. Move `captured` to `planned`\n  only after Navigator approval.\n- **Assign before starting.** Before `in_progress`, obtain explicit human Driver\n  and branch\u002FPR Delivery decisions, then update status and both fields atomically.\n  Replace a branch reference with the PR link after the PR opens.\n- **Evidence is not validation.** Record checks and isolated smoke evidence during\n  implementation, but require an explicit natural Navigator validation route and\n  acceptance before `validated`.\n- **Review before terminal closure.** Record proportionality\u002Fdebt findings. `done`\n  requires accepted validation and resolved debt action. `blocked`, `parked`,\n  `rejected`, and `promoted` require narrative reasons; `parked` also requires a\n  revisit trigger and `promoted` a Delivery target. Move terminal CRs below open\n  work, preserve Driver\u002FDelivery provenance, and clear focused CR state without\n  selecting the next item implicitly.\n- **Return a handoff.** Report RS\u002FCR, canonical status, Driver, Delivery, changed\n  files, checks, Navigator validation, limitations, unresolved decisions, and the\n  requested next action. A handoff never grants merge, publication, or release.\n- **Let Git expose concurrency.** Refresh against the approved base before final\n  handoff. Never overwrite, silently renumber, merge narratives, delete another\n  contributor's work, or use SQLite to resolve ID\u002Findex\u002Ffocus\u002Fstatus conflicts.\n  Stop for semantic conflict resolution.\n\nWhen the Navigator asks how to create, work on, or collaborate through\nRefinement Work, answer read-only and explain the complete contributor route. Do\nnot stop the explanation at terminal status: include the return handoff and how\nordinary Git conflicts protect concurrent ID, index, focus, status, assignment,\nand narrative edits. Name the linked project protocol as the durable authority.\n\nStatus remains document vocabulary, not an application state machine. Do not add\nID reservation, locks, watchers, heartbeats, stale-work automation, Markdown\nparsing, projection, synchronization, or custom Git commands without repeated\noperational evidence and separate Navigator approval.\n\nWhen the Navigator authorizes a mutable operation such as capture, select,\ncontinue, update, or implement, that request also authorizes structural repairs\nneeded to complete it without a second confirmation only when every repair is:\n\n- necessary for the requested operation;\n- deterministic from existing project evidence;\n- local to the involved Refinement documents;\n- non-destructive and reversible through Git;\n- meaning-preserving; and\n- free of unrequested status, priority, focus, identity, SQLite, configuration,\n  commit, push, publication, or release decisions.\n\nAfter completing the operation, explain in Navigator-facing project language\nwhat defect was found, what was repaired, and what was left unchanged. Do not\nlead with internal Mirror terms such as projection, artifact mismatch, or\nruntime coherence.\n\nStop only when repair would choose product meaning, delete content, resolve a\nconcurrent conflict, or expand the original request. In that case, explain the\npractical consequence, recommend the smallest safe solution, name the files it\nwould change, and ask for the missing decision. Never use legacy SQLite as a\nrecovery path.\n\nFollow the canonical file's status vocabulary and ID convention. Do not invent\nmissing narrative or an RS assignment. Do not treat journey-local UUIDs or\nlegacy display codes as project artifact identity. Git owns history, conflicts,\nand recovery; ordinary file work must not create an application-level Git\nprotocol.\n\n## Prepare Ariad Templates\n\nWhen the user asks to prepare Ariad templates or make the adopted journey\ndocumentation-ready, run:\n\n```bash\nmirror build prepare-templates --journey \u003Cslug> --method ariad\n```\n\nRender the report visibly. The operation may create missing method-declared\ntemplate files, but must preserve existing files and must not create a delivery\ncursor, execute lifecycle work, change story status, commit, push, or release.\n\n## Sync Delivery Cursor\n\nWhen the user asks to sync the initial Builder delivery cursor for an\nAriad-adopted journey, run:\n\n```bash\nmirror build sync-cursor --journey \u003Cslug> --method ariad\n```\n\nRender the cursor sync report visibly. This persists runtime resume state only.\nIt must not infer an active roadmap item, execute Pull\u002FPrepare\u002FPlan, change story\nstatus, commit, push, or release.\n\n## Inspect Roadmap And Pull Candidates\n\nWhen the user asks to see the roadmap, inspect the roadmap, show roadmap\ncandidates, see what can be pulled, choose the next story, or asks \"o que posso\npuxar agora?\", run:\n\n```bash\nmirror build pull-candidates --journey \u003Cslug> --method ariad\n```\n\nRender the configured Ariad surfaces visibly, currently `ROADMAP SNAPSHOT` and\n`■ Ariad Pull Candidates`. With an active item both are scoped to its Capability\nValue: `candidates in \u003CCV>`, a count of those outside, and a recommendation\ninside the CV (or `no remaining candidates in \u003CCV>`). Without one, the list is\n`project-wide candidates` and no pull is recommended. This is read-only: it must\nnot pull an item, update the cursor, execute lifecycle work, change story status,\ncommit, push, or release.\n\n## Show The Active Checkpoint\n\nWhen the user asks where the active item stands or asks to see the current checkpoint\nagain, or when a surface was lost, run:\n\n```bash\nmirror build show --journey \u003Cslug> --method ariad\n```\n\nReturn the `ACTIVE_CHECKPOINT` surface verbatim. It shows the stage, the cursor's\nposition, the cadence, the steps the cursor accepts next, as the resume lists them,\nand the story package's files: `index.md`, `plan.md`, and `test-guide.md` with\ntheir state, and the closure records, each present or missing. It does not replay the\noriginal checkpoint surface: that evidence lives in those records, so read the one the\nNavigator needs, such as `plan.md` before Plan approval. It is read-only and changes\nneither the cursor nor any file.\n\n## Pull And Prepare Ariad Work\n\nWhen the user asks to change testing\u002Fruntime cadence, use:\n\n```bash\nmirror build set-cadence --journey \u003Cslug> --method ariad --profile \u003Cstepwise|checkpoint|accelerated|autonomous>\n```\n\nUse `stepwise` for detailed dogfooding: Plan stops for approval unless the Navigator naturally asks the Driver to create and execute the active story Plan without another approval turn. Use `checkpoint` for normal Ariad cadence. Use `accelerated` when the Navigator trusts the Driver to complete the active story Plan and continue directly into local implementation; the runtime automatically records bounded story Plan authority and still stops at Navigator Validation. Use `autonomous` only with explicit Navigator limits, for example:\n\n```bash\nmirror build set-cadence --journey \u003Cslug> --method ariad \\\n  --profile autonomous \\\n  --limit \"stop before push or release\" \\\n  --limit \"stop on scope change\" \\\n  --limit \"stop on failing checks\"\n```\n\nThe Builder resume, `build show`, and the Builder orientation print the cadence\nprofile and, under `autonomous`, its limits. Read it there before Plan: under\n`accelerated`, Plan continues into implementation without a Navigator turn.\n\nHigher-autonomy cadence never grants permission to cross Navigator validation acceptance, debt decisions, unsafe operations, scope changes, push\u002Frelease, or Done\u002Fhistory boundaries. For an active User Story or Technical Story in `story_by_story`, `accelerated` satisfies the Plan approval gate through a complete, structurally matching, single-use receipt instead of pausing for another Navigator turn; Plan completeness and mismatch checks still apply. In current Ariad, Pull is the Navigator signal to Prepare; pulling a Delivery Story also expands it into implementable User\u002FTechnical Stories and stops for confirmation of the recommended next story.\n\nWhen the user asks to continue under the active cadence, use:\n\n```bash\nmirror build continue-lifecycle --journey \u003Cslug> --method ariad \\\n  --process \"\u003Cprocess alignment evidence>\" \\\n  --project \"\u003Cproject\u002Fdocs\u002Fartifacts alignment evidence>\" \\\n  --product \"\u003Cproduct behavior alignment evidence>\" \\\n  --history-action \"\u003Crequired to cross Done\u002Fhistory boundary>\" \\\n  --roadmap-update \"\u003Crequired to cross Done\u002Fhistory boundary>\" \\\n  --next-recommendation \"\u003Crequired to cross Done\u002Fhistory boundary>\"\n```\n\n`continue-lifecycle` may emit multiple Ariad surfaces; return every marked block verbatim in order. In `stepwise` cadence it must refuse automatic continuation. In higher-autonomy cadence it may continue only through bypassable soft stops and must still stop at hard gates when required evidence is missing.\n\nWhen the user asks to pull a roadmap item into active Ariad work, run the\ncontained Pull command with explicit item metadata:\n\n```bash\nmirror build pull-item --journey \u003Cslug> --method ariad \\\n  --item-code \u003Ccode> \\\n  --item-title \"\u003Ctitle>\" \\\n  --item-level \u003Cdelivery_story|user_story|technical_story> \\\n  --why-now \"\u003Cwhy this level now>\"\n```\n\nRender all emitted surfaces visibly. Pull may update runtime cursor active item\nand automatically run Prepare. If the pulled item is a Delivery Story, Pull also\nexpands it into implementable child stories and recommends the next\nUser\u002FTechnical Story to plan. Pull must not create a Plan, approve a checkpoint,\nimplement, validate, review, close, commit, push, or release.\n\nWhen the Pull card's source reads `not in the roadmap`, say so to the Navigator\nbefore planning: the code may be mistyped, or the roadmap behind.\n\nWhen the Navigator confirms the recommended child story after an Expand surface,\npull that child story explicitly with `--item-level user_story` or\n`--item-level technical_story` using the recommended code\u002Ftitle from the surface.\nThen plan that implementable story when requested.\n\nWhen the user asks to prepare the pulled item, run:\n\n```bash\nmirror build prepare-item --journey \u003Cslug> --method ariad\n```\n\nRender the Prepare report visibly. Prepare may update the runtime cursor last\ndelivery event, but must not create a Plan, approve a checkpoint, start\nimplementation, change story status, commit, push, or release.\n\n## Delivery Story Candidate Table Authoring Contract\n\nExpand resolves an already-authored Delivery Story package by its `index.md`\nheading code, never by folder name or arithmetic on code and title -- an\nauthored package can live under any folder a human chose. Once resolved,\nExpand reads its `## Candidate Stories` table, header-driven. The header must\ninclude these four column names (case-insensitive, any order, extra columns\nsuch as `Outcome` or `Risk` are fine):\n\n```text\n| Code | Story | Type | Status |\n```\n\nor the 5-column generated variant:\n\n```text\n| Code | Story | Type | Outcome | Status |\n```\n\nWhen authoring or reviewing a Delivery Story `index.md` by hand, use this exact\ngrammar (see `docs\u002Fproject\u002Froadmap\u002Ftemplates\u002Fdelivery-story-index.md`). If the\nNavigator proposes a different shape (for example `| Family | Scope | Type |\nRisk |`), flag the mismatch before Pull\u002FExpand runs so the table is\nExpand-compatible by construction.\n\nA pipe inside a cell is written `\\|`, as GFM writes it, and reads back as `|`;\nAriad escapes the pipes in any title it writes into a cell.\n\nIf Expand renders `\u003C\u003C\u003CARIAD:EXPAND_BLOCKED>>>` (the resolved package's table\ndoes not parse, two packages claim the same code, or a Delivery Story with no\npackage would need a story that an authored package already claims), return the\nsurface verbatim per the transport protocol, then explain what to fix: correct\nthe table header to the canonical grammar, resolve the duplicate heading, or\nauthor the Delivery Story's `index.md` with a canonical candidate table that\nlists the story already authored. Do not\nhand-edit the package's materialized children to work around a blocked Expand,\nand do not re-run Pull\u002FExpand until the Navigator has fixed the authored\ncontent.\n\n## Delivery Story Release Intent\n\nWhen the active Ariad item belongs to a Delivery Story and the Navigator\nexplicitly says the DS is expected to create a release boundary, has no release\nintent, or remains undecided, record only that planning state:\n\n```bash\nmirror build release-intent --journey \u003Cslug> --method ariad \\\n  --intent \u003Cplanned|none|undecided>\n```\n\nTo inspect without changing state, omit `--intent`. Return the `RELEASE_INTENT`\nsurface verbatim.\n\nMap only explicit meaning:\n\n- `planned` — the DS is expected to create a release boundary if completed\n  coherently;\n- `none` — the DS is explicitly not expected to create a release boundary;\n- `undecided` — the decision is intentionally unresolved and may be revisited.\n\nDo not infer intent from cadence, version changes, completed implementation,\nexisting tags, roadmap position, or a previous DS. Release intent belongs to the\nDelivery Story ancestor and is not authorization to commit, push, create a tag,\npromote stable, publish a release, or mutate a remote system. Those remain\nseparate gates.\n\n## Delivery Story Navigator Flow\n\nWhen the active Ariad work is a Delivery Story or the Navigator refers to the\ncurrent Delivery Story and says a natural-language equivalent of:\n\n- `quero seguir no nível da DS`\n- `seguir no nível da Delivery Story`\n- `use Delivery Story flow`\n- `não preciso validar cada US`\n- `aprove um plano geral da DS e eu valido no fim`\n\nrun:\n\n```bash\nmirror build set-flow-unit --journey \u003Cslug> --method ariad --unit delivery_story\n```\n\nReturn the `DELIVERY_STORY_SCOPE_CONFIRMATION` surface verbatim. Explain after\nthe surface that child User\u002FTechnical Stories remain traceable Driver work\npackages, and that choosing Delivery Story flow does not approve a Plan, start\nimplementation, validate, push, or release.\n\nThe scope confirmation is a Navigator stop. It asks whether the scope is right\nbefore any DS Plan exists. The runtime records the stop without enforcing it: the\ncursor holds `navigator_scope_confirmation` until the Plan replaces it, and\n`plan-delivery-story` does not refuse while it is pending, so the question stays\ntrue only if you wait for the answer. End the turn after the surface. Do not run\n`plan-delivery-story` in the same turn, even when the Navigator's request also\nasked for the Plan. Plan only on a later Navigator turn that confirms or corrects\nthe scope. Cadence and Plan preauthorization do not remove this stop.\n\nA Builder resume that shows `pending confirmation: navigator_scope_confirmation`\nis this same question, still open. Ask it again, or render it again with the\n`set-flow-unit --unit delivery_story` command above, and plan only on the\nNavigator's answer.\n\nA flow unit is chosen only at the Delivery Story's flow decision, after Prepare or\nExpand and before its Plan. Anywhere else `set-flow-unit --unit` refuses with one\n`Error: no flow unit was chosen: ...` line and changes nothing. Relay that reason to\nthe Navigator. Do not reset or re-pull to force the choice without their decision.\n\n`set-flow-unit` without `--unit` only inspects the current choice and renders\n`NAVIGATOR_FLOW_UNIT`.\n\nWhen the effective flow unit is `story_by_story`, preserve existing child-story\nPlan behavior. Do not silently use Delivery Story-level Plan unless the\nNavigator has selected `delivery_story` flow or explicitly asks to follow work at\nDelivery Story level.\n\n## Delivery Story Plan Ariad Work\n\nWhen the active Ariad work is a Delivery Story with\n`navigator_flow_unit=delivery_story` and the Navigator says a natural-language\nequivalent of:\n\n- `planeje a DS`\n- `planeje a Delivery Story`\n- `plan the Delivery Story`\n- `crie o plano geral da DS`\n\nrun:\n\n```bash\nmirror build plan-delivery-story --journey \u003Cslug> --method ariad \\\n  --objective \"\u003Caggregate Delivery Story objective>\" \\\n  --child \u003Cchild-work-item-code>\n```\n\nPass one `--child` argument for each known child User\u002FTechnical Story work\npackage. If child work packages are already present in the cursor, the command\nmay use them; otherwise include the known roadmap child codes. If the user names\na specific journey, pass `--journey \u003Cslug>`.\n\nReturn the `DELIVERY_STORY_PLAN_CHECKPOINT` surface verbatim. Interpret only\nafter the block. Explain that the DS-level Plan is pending approval and that no\nimplementation, validation, push, or release is authorized by planning alone.\n\n### Conditional Plan preauthorization\n\nUse conditional preauthorization only when the Navigator explicitly authorizes\none active Delivery Story by exact child identity and names the fixed next hard\nstop at Navigator Validation. Vague continuation, cadence selection, “faça tudo”,\n“não me pergunte nada”, or generic autonomy language never creates authority.\nDelivery Story preauthorization applies only to `delivery_story` flow. Exact\nUser Story and Technical Story preauthorization is handled separately under\n`story_by_story` flow below.\n\nFor an explicit matching request, include:\n\n```bash\nmirror build plan-delivery-story --journey \u003Cslug> --method ariad \\\n  --objective \"\u003Caggregate Delivery Story objective>\" \\\n  --child \u003Cevery exact child code> \\\n  --preauthorize-approval \\\n  --stop-after navigator_validation\n```\n\nReturn `DELIVERY_STORY_PLAN_CHECKPOINT`,\n`PLAN_PREAUTHORIZATION_RECORDED`, and artifact surfaces verbatim. The receipt is\nnot approval: complete the Driver-owned `plan.md` first. Required sections must\nexist and contain no empty, `Pending`, TODO\u002FTBD, or placeholder body. Never\nreplace an existing non-empty Plan with the runtime scaffold.\n\nIn the same assistant turn, after completing the Plan, consume the receipt with:\n\n```bash\nmirror build approve-delivery-story-plan --journey \u003Cslug> --method ariad \\\n  --use-preauthorization\n```\n\nOn exact match, return every approval\u002Fstart surface, implement only local approved\nwork, and stop at Navigator Validation. On `PLAN_PREAUTHORIZATION_MISMATCH`,\nreturn the bounded surface and stop at ordinary Plan approval. Never repair,\nexpand, reinterpret, or recreate authority silently. Child order is\npresentational, but addition or removal is a mismatch.\n\nCancel pending authority when the Navigator withdraws it:\n\n```bash\nmirror build cancel-delivery-story-plan-preauthorization --journey \u003Cslug> \\\n  --method ariad\n```\n\nCancellation preserves the ordinary Plan approval gate. Preauthorization never\ncrosses validation acceptance, debt, Done\u002Fhistory, commit, push, release, deploy,\npurchase, or another irreversible boundary.\n\nIf the Navigator asks to plan the Delivery Story before selecting\n`delivery_story` flow, first surface or request the flow-unit choice; do not\nsilently use DS-level Plan from the default `story_by_story` flow. Surfacing the\nchoice with `set-flow-unit --unit delivery_story` ends the turn at its scope\nconfirmation, as described in Delivery Story Navigator Flow; plan on the\nNavigator's next turn.\n\nWhen the Navigator approves a pending DS-level Plan with natural language such\nas `aprovo o plano da DS`, `plano da DS aprovado`, or `approve the Delivery\nStory plan`, run:\n\n```bash\nmirror build approve-delivery-story-plan --journey \u003Cslug> --method ariad\n```\n\nReturn every emitted Ariad surface verbatim, including\n`DELIVERY_STORY_PLAN_CHECKPOINT`, `ARTIFACTS_MATERIALIZED`, and\n`IMPLEMENTATION_STARTED` when present.\n\nPlan approval authorizes local implementation under the approved DS Plan. After\nrendering the approval surfaces, do **not** stop to ask for a separate\nimplementation command. Immediately begin implementing the approved plan: read\nthe generated `plan.md` \u002F `test-guide.md` artifacts and relevant code, edit local\nproject files, and run appropriate checks. Still stop before hard gates: unsafe\noperations, scope changes, debt decisions, push, release, deploy, purchase,\nexternally irreversible actions, and final Done\u002Fhistory boundaries remain\nexplicit Navigator authorization points.\n\n## Plan Ariad Work\n\nWhen the user asks to plan the pulled item, create a plan for the active item, or\nsays a natural-language equivalent such as `planeje o item puxado`, run:\n\n```bash\nmirror build plan-item --journey \u003Cslug> --method ariad\n```\n\nRender the Plan Checkpoint visibly, and name the plan in the reply by its\nproject-relative path: the card's `story package`, then `\u002Fplan.md`. The card holds no plan: it names the story files,\n`index.md`, `plan.md`, and `test-guide.md`, each with its state and the sections\nstill to author. The plan is read in `plan.md`. Right after `plan-item` that file\nis usually the scaffold, so there is no plan to present yet: present it after it\nis authored, by the sequence below. Keep runtime cursor fields compact; do not let\ntechnical metadata replace the plan itself.\n\nPlan may update runtime cursor checkpoint state and may create\u002Fupdate the\nPlan-stage story package (`index.md`, `plan.md`, and `test-guide.md`) only for an\nimplementable User Story or Technical Story. Delivery Stories are never planned\nas the implementable unit; they must expand first. Plan must not approve the\ncheckpoint, start implementation, change implementation files for the pulled\nitem, change story status, commit, push, or release.\n\n### Author the plan before asking for approval\n\nPlan writes `plan.md` as a scaffold: template sentences with the item's title\npasted in. It is not a plan. The Objective, Scope, Acceptance Behavior, and\nValidation Route are what the Navigator approves from: write them for this\nstory, in Navigator-facing language. The Non-Goals, Implementation Contract,\nStop Conditions, and Approval Gate may stand as written when they are true. Unless\nthe Plan checkpoint or `build show` names `index.md` authored, write its story\nstatement, Outcome, and Acceptance Behavior too: it may say scaffold, partly\nauthored, or incomplete.\n\nThe sequence:\n\n1. `plan-item`.\n2. Author `plan.md`, and `index.md` unless the Plan checkpoint or `build show`\n   names it authored.\n3. Run `build show` and return its `ACTIVE_CHECKPOINT` block. It must read\n   `✓ plan.md — authored`; if it does not, author what it names and run it again.\n4. Present the plan from `plan.md`, section by section: the Objective, Scope,\n   Non-Goals, Acceptance Behavior, and Validation Route as the file states them,\n   not paraphrased into claims the file does not make. Then ask for approval.\n5. On approval, `approve-plan`.\n\nThe runtime checks structure, not quality: one real line under a heading passes\nit. That check is a floor. The bar is a plan the Navigator can approve from.\n\n`approve-plan` refuses with `CHECKPOINT_REFUSED` while any section it requires is\nmissing, empty, pending, or still the scaffold's, and names each by its heading.\nA refusal means: author what it names, run `build show`, and present the plan\nagain. Do not run `approve-plan` again in the same turn as if the approval were\nstill standing: the Navigator approved a plan that did not exist yet.\n\n`done-item` refuses the same way while the story's `index.md` still says what\nExpand or Plan wrote (\"I want to \u003Ctitle>\"). Write the story it is before closing\nit.\n\n### Conditional story Plan preauthorization\n\nUse story-level conditional preauthorization for one active User Story or\nTechnical Story in `story_by_story` flow through either of two routes:\n\n- **natural explicit delegation in any cadence** — the Navigator asks the Driver\n  to create the active story Plan and execute it without another Plan approval\n  turn, for example `crie o plano e execute sem que eu precise autorizar`,\n  `faça o plano e implemente com preautorização concedida`, or an equivalent\n  natural phrase;\n- **accelerated cadence** — `plan-item` automatically records bounded story Plan\n  authority, so the Driver completes the Plan and continues without a Plan stop.\n\nThe Navigator does not need to recite story identity, sibling exclusions,\nfingerprint policy, mismatch behavior, or the Validation boundary. Ariad derives\nthose safeguards from the active cursor and method: exact active item and level,\n`story_by_story` flow, current generation, no sibling scope, complete Plan,\nsingle use, bounded mismatch fallback, and stop at Navigator Validation.\n\nVague continuation such as `continue`, an isolated `faça tudo`, or `não me\npergunte nada` does not create stepwise story authority. Selecting `accelerated`\nis itself the explicit cadence decision that authorizes Plan continuation for\nactive implementable stories. For natural explicit delegation, run:\n\n```bash\nmirror build plan-item --journey \u003Cslug> --method ariad \\\n  --preauthorize-approval \\\n  --stop-after navigator_validation\n```\n\nIn `accelerated` cadence, run ordinary `plan-item` without the explicit flag; the\nruntime automatically records bounded story Plan authority and emits the same\nreceipt surface. Do not pause for Navigator approval after either route.\n\nReturn `PLAN_CHECKPOINT`, `PLAN_PREAUTHORIZATION_RECORDED`, and artifact surfaces\nverbatim. Preserve existing `index.md`, `plan.md`, and `test-guide.md` bytes. The\nreceipt is not approval: the Driver-owned Plan must be authored, as in\n[Author the plan before asking for approval](#author-the-plan-before-asking-for-approval),\nbefore authority can be consumed. The Objective, Scope, Acceptance Behavior, and\nValidation Route must be written for this story, not the scaffold's sentences, and\nthe Non-Goals and Implementation Contract must not be empty. A plan that is not\nauthored returns `PLAN_PREAUTHORIZATION_MISMATCH` with reason `plan_incomplete` and\nthe sections still to author.\n\nIn the same assistant turn, after completing the exact story Plan, run:\n\n```bash\nmirror build approve-plan --journey \u003Cslug> --method ariad \\\n  --use-preauthorization\n```\n\nOn exact match, return every approval and `IMPLEMENTATION_STARTED` surface,\nimplement only the active story locally, and stop at Navigator Validation. On\n`PLAN_PREAUTHORIZATION_MISMATCH`, return the bounded surface and stop at ordinary\nPlan approval; never repair, reinterpret, or recreate authority silently.\n\nCancel pending story authority when the Navigator withdraws it:\n\n```bash\nmirror build cancel-plan-preauthorization --journey \u003Cslug> --method ariad\n```\n\nCancellation preserves the ordinary Plan gate. Story authority is private,\nsingle-use, cursor-generation-bound, and cannot authorize a sibling story,\nValidation acceptance, Debt Review, Done\u002Fhistory, commit, push, release, deploy,\npurchase, or another irreversible action.\n\nWhen the Navigator approves an ordinary Plan checkpoint, run:\n\n```bash\nmirror build approve-plan --journey \u003Cslug> --method ariad\n```\n\nIf the user asks to implement while the Plan checkpoint is pending, run the guard\nbefore doing any implementation work:\n\n```bash\nmirror build check-implementation --journey \u003Cslug> --method ariad\n```\n\nRender the deterministic `IMPLEMENTATION_GUARD` surface. If the guard reports\nthat Navigator approval is required, return the surface and stop. Do not mutate\nfiles.\n\n## Closure Records\n\n`validation.md`, `review.md`, `coherence.md`, and `done.md` are records\nthat Ariad seals: their last line is `\u003C!-- ariad-seal sha256:… -->`. A closure\ncommand rewrites a record only while its seal still matches. Anything else is\nleft exactly as it is, and the checkpoint says `preserved`.\n\n`preserved` is not an error. It means a person wrote or edited the file, and\ntheir version stands. The checkpoint's fields are in the surface you render, and\nthey were not written to the file.\n\n- Never delete, rewrite, or re-seal an authored record to make Ariad write it.\n- Never copy a seal line into a file.\n- If the Navigator wants Ariad's record in the file, ask how they want their\n  own notes kept.\n\n## Delivery Story Validation And Closure\n\nWhen the active Ariad work is a Delivery Story with\n`navigator_flow_unit=delivery_story` and an approved aggregate DS Plan, route\nnatural Navigator requests for aggregate DS closure through the Delivery Story\nruntime commands.\n\nFor natural validation requests such as `valide a DS`, `valide a Delivery\nStory`, or `validação da DS aceita`, run:\n\n```bash\nmirror build validate-delivery-story --journey \u003Cslug> --method ariad \\\n  --summary \"\u003Caggregate DS validation evidence>\" \\\n  --navigator-accepted\n```\n\nFor DS-level debt review requests, run:\n\n```bash\nmirror build review-delivery-story --journey \u003Cslug> --method ariad \\\n  --decision \u003Cno_action|defer|pay_now> \\\n  --summary \"\u003CDS-level debt review summary>\"\n```\n\nFor DS-level Done requests after Debt Review and Navigator closure confirmation,\nfirst align authored project state: mark the resolved Delivery Story package,\nevery known child package\u002Fcandidate row, and every canonical roadmap table row\nfor the DS as Done. Then run:\n\n```bash\nmirror build done-delivery-story --journey \u003Cslug> --method ariad \\\n  --summary \"\u003CDS-level done\u002Fhistory summary>\"\n```\n\nThe command runs an authored roadmap closure preflight before cursor or artifact\nmutation. If any DS package, known child package\u002Fcandidate row, or canonical\nroadmap row remains non-Done, the runtime refuses Done before cursor or artifact mutation and names project-relative files to align. The agent owns semantic\nMarkdown updates; the runtime verifies explicit status evidence and never invents\nproject meaning.\n\nDS-level Coherence is not a separate lifecycle stage before Done. It is checked\ninside Done only after the authored status preflight passes, so the final surface\ncan truthfully state that docs, roadmap, cursor, artifacts, and next-pull readiness\nremain consistent after closure.\n\nReturn every `DELIVERY_STORY_CLOSURE_CHECKPOINT` surface verbatim. Explain after\nthe block that child User\u002FTechnical Stories remain evidence units and that\npush\u002Frelease remain separate hard gates. Do not use these DS-level closure\ncommands when the effective flow unit is `story_by_story`; preserve existing\nchild-story lifecycle behavior in that mode.\n\n## Validate Ariad Work\n\nAfter implementation is complete and before moving to Debt Review or Done,\nrender the Validation checkpoint:\n\n```bash\nmirror build validate-item --journey \u003Cslug> --method ariad \\\n  --implementation-complete \\\n  --check \"\u003Cautomated check command or evidence>\" \\\n  --checks-status \u003Cpassed|failed|not_run> \\\n  --e2e-decision \u003Crequired|not_required|waived|skipped> \\\n  --e2e-evidence \"\u003CE2E evidence or waiver\u002Fskipped reason>\" \\\n  --navigator-route \"\u003CNavigator-visible validation route>\" \\\n  --navigator-accepted \\\n  --expected-observation \"\u003Cwhat the Navigator should observe>\" \\\n  --pass-condition \"\u003Cwhat counts as pass>\" \\\n  --fail-condition \"\u003Cwhat counts as fail>\"\n```\n\nIf the Navigator has already performed and accepted the validation route, also\npass `--navigator-accepted`. Providing a route is not the same as acceptance.\n\nRender the deterministic `VALIDATION_CHECKPOINT` surface. If required evidence\nis missing or Navigator validation has not been accepted, return the surface and\nstop; do not advance to Debt Review, Done, commit, push, or release.\n\n## Review Ariad Debt\n\nAfter Validation has passed and before moving to Done, render the Debt Review\ncheckpoint:\n\n```bash\nmirror build review-item --journey \u003Cslug> --method ariad \\\n  --debt \"\u003Cdebt finding, or No debt found>\" \\\n  --decision \u003Cpending|no_action|defer|pay_now> \\\n  --defer-reason \"\u003Crequired when decision=defer>\" \\\n  --revisit-trigger \"\u003Crequired when decision=defer>\"\n```\n\nRender the deterministic `DEBT_REVIEW_CHECKPOINT` surface. If the decision is\n`pending`, `defer` without a reason\u002Ftrigger, or `pay_now`, stop at the debt\ndecision checkpoint. `pay_now` must route through a future Refactor loop before\nDone. Do not advance to Done, commit, push, or release while the debt decision\nis unresolved.\n\n## Check Ariad Coherence\n\nAfter Debt Review is complete, verify Process, Project, and Product alignment:\n\n```bash\nmirror build coherence-item --journey \u003Cslug> --method ariad \\\n  --process \"\u003Cprocess alignment evidence>\" \\\n  --project \"\u003Cproject alignment evidence>\" \\\n  --product \"\u003Cproduct alignment evidence>\"\n```\n\nRender the `COHERENCE_CHECKPOINT` surface. If it reports `pending_coherence`,\ncorrect the missing evidence and rerun the same command. Reentry is valid only\nfor the exact `navigator_coherence` \u002F `last_delivery_event=coherence` state. It\nre-evaluates the evidence; it does not bypass Coherence. Unrelated pending\nconfirmations stay blocked, and `done-item` never consumes\n`navigator_coherence`.\n\n## Close Ariad Done\n\nAfter Coherence is complete and the Navigator confirms there is nothing else to\ndo in the story, render the Done checkpoint:\n\n```bash\nmirror build done-item --journey \u003Cslug> --method ariad \\\n  --history-action \"\u003Ccommit\u002Fhistory action taken or proposed>\" \\\n  --roadmap-update \"\u003Croadmap\u002Fstory package update>\" \\\n  --next-recommendation \"\u003Cnext Pull, parent collapse, or release boundary>\"\n```\n\nRender the deterministic `DONE_CHECKPOINT` surface. Done must name the history\naction, roadmap\u002Fstory package update, and next Ariad movement. Do not push or\nrelease unless the effective policy explicitly allows it.\n",{"name":5,"description":7,"user-invocable":36},true,"main","4402e28990454797b18d84035e611c81c1c7dd1b",".pi\u002Fskills\u002Fmm-build",12,"https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai","2026-11-14 01:47:51",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":36},[46,49,52],{"tool":47,"command":48},"npx","npx skills add mirror-mind-ai\u002Fmirror --skill mm-build",{"tool":50,"command":51},"bunx","bunx skills add mirror-mind-ai\u002Fmirror --skill mm-build",{"tool":53,"command":54},"pnpm","pnpm dlx skills add mirror-mind-ai\u002Fmirror --skill mm-build","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fmm-build\u002FSKILL.md",[],[58,67,75,83,89,101],{"skillNo":59,"name":60,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":31},"01M71DRDAQS0MBZT50V4K24RVT","ext:claude-only","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fextension-catalog\u002Fhome\u002Fextensions\u002Fext-claude-only\u002Fskills\u002Fclaude\u002FSKILL.md",[],[64,65,66],"ext:claude only","claude only","only",{"skillNo":68,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":31},"01M71DRBQ9R7RX6779KRGX7H49","ext-beta","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fextension-catalog\u002Fhome\u002Fextensions\u002Fext-beta\u002Fskills\u002Fpi\u002FSKILL.md",[],[73,74],"ext beta","beta",{"skillNo":76,"name":77,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":31},"01M71DR9Z5NGMW0STW3E238KHR","ext-alpha","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fextension-catalog\u002Fhome\u002Fextensions\u002Fext-alpha\u002Fskills\u002Fpi\u002FSKILL.md",[],[81,82],"alpha","ext alpha",{"skillNo":84,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":31},"01M71DR871VEZSZH8RMQTGQD79","ext:alpha","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fextension-catalog\u002Fhome\u002Fextensions\u002Fext-alpha\u002Fskills\u002Fclaude\u002FSKILL.md",[],[85,81],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":31},"01M71DR5ZKBAF01TS3C8E02Z7K","ext-tools","Fixture extension for the CV22.DS7.TS4 dispatch corpus","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fext-dispatch\u002Ftools\u002FSKILL.md",[],[96,97,98,26,99,100],"Tools","ext tools","extension","dispatch","fixture",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":31},"01M71DR44APEA202QDS68E30DX","ext-silent","Fixture extension that registers no subcommands","https:\u002F\u002Fgithub.com\u002Fmirror-mind-ai\u002Fmirror\u002Fblob\u002Fmain\u002Fts\u002Ftest\u002Ffixtures\u002Fext-dispatch\u002Fsilent\u002FSKILL.md",[],[108,98,100],"ext silent"]