--- name: canon-addition description: "Use when evaluating a proposed new canon fact against an existing worldloom world. Produces: adjudication verdict + (on accept outcomes) new CF/CH atomic-YAML records under _source/, extension/touched_by_cf/modification_history appends to affected M- / OQ- / SEC-* / CF records, and a hybrid PA adjudication record under adjudications/; (on non-accept outcomes) PA record only. All mutations route through the patch engine via mcp__worldloom__submit_patch_plan; direct writes to _source/ are blocked by Hook 3." user-invocable: true arguments: - name: world_slug description: "Directory slug of an existing world under worlds//. Pre-flight aborts if the directory is missing." required: true - name: proposal_path description: "Path to a markdown brief: a new-fact proposal OR a continuity-audit retcon-proposal card (see proposal-normalization.md §Retcon-Proposal Inputs). If omitted, Phase 0 interviews the user." required: false --- # Canon Addition Evaluates a proposed canon fact against an existing world's atomic-source canon. On accept outcomes, assembles a single patch plan that creates new CF/CH records, extends affected mystery-reserve / open-question / section / CF records, and appends a hybrid PA record — all applied atomically by the engine. On non-accept outcomes, the patch plan carries only the PA record. Do NOT call `mcp__worldloom__submit_patch_plan` until: (a) pre-flight resolves `worlds//` and allocates the next `PA-` (plus `CF-` / `CH-` for accept branches; plus `M-` / `OQ-` when Phase 7 Mystery Curator Rule-7 obligation or Phase 10 OQ pressure scan are likely to manufacture new entries) via `mcp__worldloom__allocate_next_id`; (b) Phase 11 produces an explicit verdict; (c) for accept branches the Phase 13a patch plan is assembled and Phase 14a `validate_patch_plan` returns clean (mechanical layers) AND skill-side Tests 9, 10, 11, 12, 13, 14 + judgment layers of Tests 3, 6, 8 record PASS with one-line rationale; (d) the user has explicitly approved the deliverable summary and the skill has issued an `approval_token` via the canonical signer (`node tools/world-mcp/dist/src/cli/sign-approval-token.js [--world-root ] ` per `docs/HARD-GATE-DISCIPLINE.md` §Issuing a token). The gate is absolute under Auto Mode — invoking the skill is not approval. Approval tokens are single-use, plan-bound, default-20-minute-expiry. ## Process Flow ``` Pre-flight (allocate_next_id PA/CF/CH; get_context_packet for world state; get_canonical_vocabulary for domain/verdict/mystery/record-construction/CF-type enums; find_named_entities for pre-figuring scan) | v Phase 0: Normalize the Proposal (parse OR interview; classify fact type) | v Phases 1–6: Scope, Invariants, Capability, Prerequisites, Diffusion, Consequence Propagation across 13 exposition domains | v Escalation Gate → 6 parallel critic sub-agents → Phase 6b synthesis | v Phases 7–10: Counterfactual Pressure, Contradiction Classification, Repair Pass, Narrative and Thematic Fit | v Phase 11: Verdict (phase-cited) | +--- accept ----> Phase 12a (modification_history axis-(c) judgment) | Phase 13a (PatchOperation[] assembly) | Phase 14a (validate_patch_plan + judgment Tests 9/10/11/12/13/14 | + judgment layers of Tests 3/6/8) | +--- non-accept -> Phase 13b (PA-only patch plan) | v HARD-GATE → submit_patch_plan(plan, approval_token) ``` ## Output **Accept branch** (`ACCEPT` / `ACCEPT_WITH_REQUIRED_UPDATES` / `ACCEPT_AS_LOCAL_EXCEPTION` / `ACCEPT_AS_CONTESTED_BELIEF`) — one `submit_patch_plan` call carrying: - `create_cf_record` op per accepted CF (engine writes `_source/canon/CF-.yaml`). `ACCEPT_AS_LOCAL_EXCEPTION` → `status: soft_canon`; `ACCEPT_AS_CONTESTED_BELIEF` → `status: contested_canon`. Clarificatory retcons (`change_type: clarification`, typically `retcon_type: A`) emit no `create_cf_record`. - `create_ch_record` op for the Change Log Entry (`_source/change-log/CH-.yaml`). - For each section the verdict cites in `touched_by_cf` on an EXISTING CF that this plan extends with new file-class coverage: an `update_record_field` op extending the existing CF's `required_world_updates` PRECEDES the `append_touched_by_cf` op on the target SEC record. For new CFs being created in the same plan, the `create_cf_record` op's initial `required_world_updates` value satisfies the bidirectional check without a separate `update_record_field` op (engine validator is final-state, not op-level — see `references/engine-envelope-shape.md` §8). Engine fail-fast rejects plans lacking the bidirectional pair (SPEC-14) in either case. - For each affected SEC (whether the CF is new or existing): an `append_extension` op carrying prose annotation describing the CF's contribution to that file class is REQUIRED alongside the `append_touched_by_cf` op. **`append_touched_by_cf` alone does NOT satisfy `rule5_no_consequence_evasion`** — the validator credits only `create_sec_record`, `append_extension`, and `update_record_field` on a SEC. Pair every `append_touched_by_cf` with an `append_extension` on the same SEC; see `references/engine-envelope-shape.md` §8 for the validator-behavior rationale and `examples/accept-with-required-updates.md` for the worked pairing. - `append_extension` op per Mystery Reserve firewall extension (target `M-.yaml`). - `append_modification_history_entry` op per CF identified by the Phase 12a axis-(c) judgment. - `create_oq_record` op per new Open Question raised by reasoning, with the resulting `OQ-` cited in the PA frontmatter's `open_questions_touched[]`. - `append_extension` op per `OQ-.yaml` for PRESSURED items per Phase 10 OQ scan (caution annotation, scope narrowing, cross-reference clause); pressured items appear in the PA frontmatter's `open_questions_touched[]` alongside NEW and RESOLVED items. See `references/counterfactual-and-verdict.md` §Phase 10 for the PRESSURED / NEW / RESOLVED / UNCHANGED classification rules. - `append_adjudication_record` op carrying SPEC-14 PA frontmatter (`pa_id`, canonical-enum `verdict`, `originating_skill: "canon-addition"`, `change_id`, four `*_touched` arrays) + `body_markdown` per §PA body_markdown structure. Per SPEC-17 Track C1, modification_history[] is the canonical post-SPEC-13 audit surface for CF retroactive modifications. The engine's `append_modification_history_entry` op writes only to that field; this skill does NOT append a parallel notes paragraph merely to mirror the structured audit entry. **Non-accept branch** (`REVISE_AND_RESUBMIT` / `REJECT`) — single-op patch plan with `append_adjudication_record` only. No `_source/` mutations. ## World-State Prerequisites `docs/FOUNDATIONS.md` plus the world-state slice the proposal touches load via `mcp__worldloom__get_context_packet(task_type='canon_addition', seed_nodes=[], token_budget=10000)` per `docs/CONTEXT-PACKET-CONTRACT.md`. The packet delivers Kernel + Invariants + relevant CF/CH/M/OQ records + named-entity neighbors + section context with completeness guarantees. Direct `Read` of `_source//` is redirected to MCP retrieval by Hook 2 — do not bulk-read. For specific records, use `mcp__worldloom__get_record(record_id)`. For `find_sections_touched_by(cf_id)` use the dedicated tool. For pre-figuring scans of named entities the proposal commits, use `mcp__worldloom__find_named_entities(names, node_type_filter=['character_record', 'diegetic_artifact_record'])` — server-side filtering returns only canonical matches with mentions in those record types. Those mentions are the pre-figuring matches that MUST cite the originating `DA-` / `CHAR-` in the new CF's `source_basis.derived_from` per Rule 6 (No Silent Retcons). When the packet returns `delivery_status: persisted_with_summary`, recover through `mcp__worldloom__get_persisted_packet_slice` or `mcp__worldloom__get_records` per `references/retrieval-tool-tree.md` instead of falling back to repeated single-record calls. Use `references/retrieval-tool-tree.md` for the phase-by-phase retrieval-tool decision tree, including when to pair `find_named_entities` with `search_nodes` for prose-body discovery. If `worlds//` is missing, abort and instruct the user to run `create-base-world` first. ## Procedure 1. **Pre-flight.** Normalize `world_slug` (strip `worlds/` prefix; verify `[a-z0-9-]+`). Allocate IDs via `mcp__worldloom__allocate_next_id(world_slug, id_class)`: `'PA'` always; `'CF'` / `'CH'` for accept branches; `'M'` / `'OQ'` when Phase 7 (Mystery Curator Rule-7 obligation) or Phase 10 (OQ pressure scan + new latent-burden surfaces) are likely to manufacture new entries — frequently true for proposals introducing new institutions, hazards, or taboos; defer M / OQ allocation to Phase 11+ if only existing entries are touched. Load the context packet (per §World-State Prerequisites). Look up canonical vocabularies via `mcp__worldloom__get_canonical_vocabulary({class})` for `domain`, `verdict`, `mystery_status`, `mystery_resolution_safety`, `invariant_category`, `entity_kind`, `sec_file_class`, `change_type`, `mystery_reserve_effect`, `revision_difficulty`, and `cf_type` so values are validated at reasoning time, eliminating post-write vocabulary-drift fails. Run the pre-figuring scan if the proposal names specific entities. Load `templates/critic-prompt.md` and `templates/critic-report-format.md` if escalation is likely (proposal commits to >3 exposition domains in `domains_affected`, introduces a new invariant-level rule, or revises an existing invariant) — the only template files that load; CF/CH/PA schemas are engine-owned and validated by `record_schema_compliance`. 2. **Phase 0: Normalize the Proposal.** Load `references/proposal-normalization.md`. Parse `proposal_path` if provided, otherwise interview. When `proposal_path` points at a story-promotion proposal package, parse the top-level `candidate:` mapping as the proposed CF body and treat top-level `proposal_evidence:` as audit-only context for Phase 0 provenance, Phase 2 scope, Phase 4 mystery, and Phase 8 contradiction analysis; do not copy `proposal_evidence` into the accepted CF payload. Classify fact type(s); run the mandatory `references/proposal-normalization.md` §Prior-Silence Acknowledgment and §Misrecognition Probe sub-steps; selectively expand the context packet via `get_neighbors` / `find_sections_touched_by` for the file classes the classification implicates. For proposed CFs whose `domains_affected` introduce a domain no prior CF covered, record either a one-line prior-silence acknowledgment in `cf.notes` / `cf.source_basis` or a "not previously silent" rationale in the PA `body_markdown` `## Phase 0 — Proposal Normalization, Prior-Silence, and Misrecognition Probe` sub-section. Every proposal records either a misrecognition layer (with `truth_scope.diegetic_status` plus at least one `epistemic_profile.distortion_vectors[]` or `knowledge_exclusions[]` entry) OR `misrecognition_probe: NONE` with a one-line rationale in the same Phase 0 sub-section. **Proposal self-assessment is advisory, not authoritative** — `canon_safety_check` blocks feed Phase 2 and Phase 6b but never replace independent verification. 3. **Phases 1–6: Scope → Consequence Propagation.** Load `references/consequence-analysis.md`. Run Phases 1–6 ending with the Escalation Gate. The 13 Phase 6 **exposition domains** are: everyday life, economy, law, religion, warfare, status order, kinship, architecture, mobility, environment, taboo/pollution, language/slang, memory/myth — distinct from the FOUNDATIONS §Mandatory World Files enumeration; do not conflate. The escalation gate fires when (a) the proposal's `domains_affected` substantively commits to >3 exposition domains, (b) a new invariant-level rule is introduced (ontological / causal / distribution / social / aesthetic), or (c) an existing invariant is revised. **Substantive-commitment vs investigation-touch**: Phase 6 inspects all 13 domains by definition; only domains receiving a `domains_affected` entry count toward the threshold. Secondary surfaces and tangential consequences (effects flowing from existing CFs rather than the new commitment) do NOT count. **De-escalation**: inline four-lens analysis (Continuity Archivist + Systems-Economy + Theme-Tone + Mystery Curator, adopted by the main agent) is acceptable in lieu of parallel six-critic dispatch when the proposal scores LOW on novelty (`distinctiveness ≤ 3` AND `propagation_value ≤ 2` AND `integration_burden ≤ 2`) AND fits a documented absorption pattern: sub-occasion-within-parent-CF (CF-45 lock-night precedent), sub-specialty-within-parent-subtype (CF-34 / CF-35 / CF-42 / CF-43 precedents), retcon-clarification (`retcon_type: A`), pre-figured-by-existing-DA (CF-38 / CF-45 precedent), or named-instance-of-deferred-OQ (an OQ- record explicitly deferred a class of detail; the new CF resolves a single instance from that class without resolving the OQ itself). The named precedents are illustrative; equivalent absorption patterns from non-Animalia worlds qualify when the precedent CF or OQ is named in the de-escalation justification. The choice MUST be justified in the PA's notes section by naming the precedent CF or OQ and the absorption pattern; default behavior is parallel dispatch when in doubt. If the gate fires AND no de-escalation criterion applies, dispatch six parallel critic sub-agents using `templates/critic-prompt.md` (per-role substitution; do NOT pass the template literally to all six) and `templates/critic-report-format.md`. Produce Phase 6b multi-critic synthesis before Phase 7. 4. **Phases 7–11: Counterfactual → Adjudication.** Load `references/counterfactual-and-verdict.md`. Run Phases 7–10, then synthesize the Phase 11 verdict citing specific phase findings. Vague verdicts fail Test 9. 5. **Branch on verdict.** - **Accept** → Phases 12a → 13a → 14a → HARD-GATE → 15a (submit). For clarificatory retcons (`retcon_type: A`), no `create_cf_record` is emitted and the axis-(c) framing shifts to "does the correction change how a future reader should interpret the target CF's domain-file annotations?" — see `references/proposal-normalization.md` §Retcon-Proposal Inputs. - **Non-accept** → assemble a PA-only patch plan whose `body_markdown` carries the Phase 0–11 analysis plus a Resubmission Menu (REVISE) or Why-This-Cannot-Be-Repaired section (REJECT) naming specific invariants / genre-contract elements / Mystery Reserve entries. HARD-GATE fires before submit; user may approve, request revision, or override (Phase 14b override logs to PA per Rule 6). 6. **Phase 12a (accept-only): modification_history scan — axis-(c) judgment.** Inputs: CFs in the proposal's `derived_from_cfs` (axis a — verify each names a genuine semantic parent: EXTENDS / NARROWS / REPAIR-SPLIT, not mere conceptual adjacency; capture non-derivational relationships either in the new CF's `prerequisites` when the new CF USES the candidate's mechanic as substrate — copper-silver denomination, posting-wall infrastructure, etc. — or in the new CF's `notes` when the relationship is orthogonal cross-reference. CF-45 precedent: CF-15 canal substrate → prerequisites; CF-24 posting-wall mechanism → prerequisites; CF-38 Brinewick orthogonal-coexistence → notes) and CFs named in Phase 8 soft-contradiction findings (axis b). For each candidate, apply the **axis-(c) decision test** (load-bearing): after the new CF exists, does a future reader of the existing CF *alone* need to know about the relationship to read it correctly? **YES** → substantive extension; emit `append_modification_history_entry` op. **NO** → cross-reference only; capture in the new CF's `notes`, not the existing CF's `modification_history`. Named-polity-instance commitments on abstract polity-asymmetric distributions qualify (the axis CF's distribution stays abstract; its `modification_history` records the named instance). Phase 6b critic mod_history recommendations are **advisory**; the axis-(c) test governs and overrides are documented in the PA's Phase 6b Synthesis section. The mechanical layer — `find_impacted_fragments` retrieval and `rule6_no_silent_retcons` validator enforcement — runs in `validate_patch_plan` at Phase 14a; this step is the semantic gate the validator cannot make. 7. **Phase 13a: Patch plan assembly.** Build a single `PatchOperation[]` per §Output. The full envelope shape, per-op payload convention, file-class-to-directory mapping for `target_file` paths, `expected_id_allocations` per-class format, `approval_token` placeholder convention, the `required_world_updates` SEC-only restriction, the bidirectional pointer's final-state semantics, validate/submit-by-size, failure-mode response codes (including retrieval freshness diagnostics), and worked examples are documented in [`references/engine-envelope-shape.md`](references/engine-envelope-shape.md). Bidirectional pointer essentials: for CFs created in the same plan, the `create_cf_record` op's initial `required_world_updates` value satisfies the validator's bidirectional check; explicit `update_record_field` ops are required only when extending an EXISTING CF's `required_world_updates` for a new `append_touched_by_cf` on an existing SEC. The `required_world_updates` field accepts ONLY SEC file classes (the seven mandatory prose concerns); invariant extensions, mystery-reserve entries, open-question entries, and other non-SEC mutations are tracked in CH `downstream_updates[]` (free prose) per `references/engine-envelope-shape.md` §7. Query `mcp__worldloom__describe_envelope_schema(op_kind?)` for the deployed envelope and per-op payload shapes before assembling the plan. The canonical source files remain `tools/patch-engine/src/envelope/schema.ts` plus the JSON schemas under `tools/validators/src/schemas/`; the references doc cites the relevant files and operational conventions. **Block population (per SPEC-09)**: For each `create_cf_record` op in the assembled plan, populate `epistemic_profile` and `exception_governance`, or set each to the `n_a`-with-fact-type-rationale form per `docs/FOUNDATIONS.md` §Canon Fact Record Schema. Query `mcp__worldloom__get_canonical_vocabulary({class: 'cf_type'})` for the runtime source-of-truth taxonomy and per-value coupling before deciding whether each block is required. The validator-internal helpers `requiresEpistemicProfile(cf.type)` and `requiresExceptionGovernance(cf.type)` consume the same shared vocabulary in `record_schema_compliance`; they are validator implementation details, not the operator lookup path. If a block applies, populate it from the proposal's diffusion analysis (Phase 5) and counterfactual-pressure findings (Phase 7). If a block does not apply, emit `n_a` with a rationale containing a fact-type keyword from `docs/FOUNDATIONS.md` §Ontology Categories. If the skill cannot determine whether a block applies, surface the ambiguity to the user rather than defaulting to `n_a`. **Accepted-CF approval provenance**: Every `create_cf_record` payload MUST set `source_basis.direct_user_approval: true`. This value records that the CF is being created only after this skill's Phase 11 verdict, Phase 14a validation, explicit HARD-GATE approval, approval-token issuance, and patch-engine submission. If the proposal came from `story-fact-promotion-to-canon`, do not copy the proposal package's pre-acceptance `direct_user_approval: false` into the accepted CF; transform it to `true` only inside the accepted `create_cf_record` payload after this skill's approval boundary is satisfied. Do not copy story-promotion `proposal_evidence` into `source_basis`; preserve it in the proposal package and PA analysis as audit context. 8. **Phase 14a: Validation.** Call `mcp__worldloom__validate_patch_plan(plan)`. For envelopes >50KB, use the validate CLI path instead: `node tools/world-mcp/dist/src/cli/validate-patch-plan.js [--world-root ] `. The CLI resolves the project root by explicit flag, `WORLDLOOM_ROOT`, then marker auto-discovery from cwd. The validator exercises mechanical layers: `record_schema_compliance`, `id_uniqueness`, `cross_file_reference`, `touched_by_cf_completeness`, `modification_history_retrofit`, `yaml_parse_integrity`, plus Rules 1, 2, 4, 5, 6, 7, 11, 12. Use the response's `validators_run[]` entries as the mechanical-layer pass/fail/skipped confirmation source for the Phase 14a Validation Checklist; a `skipped` validate response has `validators_run: []` because no validator ran. Loop back to the originating Phase on any fail; fix envelope shape before submit on any `skipped` status. Record all 14 tests below as PASS or FAIL with a one-line rationale in the PA `body_markdown` "Phase 14a Validation Checklist" section; bare PASS is FAIL. Tests 1-10 preserve the existing numbering; Tests 11 and 12 append the SPEC-09 action-space and redundancy judgment layers; Test 13 appends the SPEC-18 misrecognition-probe judgment layer; Test 14 appends the OQ-pressure-scan-completion judgment layer. 1. **Domains populated (Rule 2)** — mechanical (validator: `rule2_no_pure_cosmetics`). 2. **Fact structure complete (Rule 1)** — mechanical (`rule1_no_floating_facts`). 3. **Stabilizers for non-universal scope (Rule 4)** — mechanical layer (`rule4_no_globalization_by_accident`); **judgment layer**: stabilizer-quality assessment — does each stated mechanism credibly throttle universalization, or is it nominal? 4. **Consequences materialized (Rule 5)** — mechanical (`rule5_no_consequence_evasion`). 5. **Retcon policy observed (Rule 6)** — mechanical (`rule6_no_silent_retcons` + `modification_history_retrofit`). 6. **Mystery Reserve preserved (Rule 7)** — mechanical layer (`rule7_mystery_reserve_preservation`); **judgment layer**: forbidden-answer overlap check against MR `disallowed cheap answers` lists is semantic — the validator catches `status: forbidden` + `future_resolution_safety` mismatches but cannot decide whether a stated reading collides with a forbidden answer. 7. **Required updates enumerated AND patched** — mechanical (engine fail-fast on bidirectional pointer + `touched_by_cf_completeness`). 8. **Stabilizer mechanisms named** — mechanical layer (Phase 7 stabilizers must name a concrete mechanism); **judgment layer**: hand-wave detection (e.g., "people just don't use it much" without mechanism) is semantic. 9. **Verdict cites phases** — judgment only. Verdict reasoning cites specific phase findings; vague verdicts fail. 10. **No specialness inflation (Rule 3)** — judgment only (Rule 3 is unmechanized per archived SPEC-04 §Risks). CF `statement`, `visible_consequences`, `distribution` clauses do not rely on unmotivated `#1` / `most` / `world-first` / `unparalleled` / `the only` claims. Either (a) cite a concrete stabilizer mechanism explaining the primacy, or (b) soften to pragmatic register (`among the foremost`, `notably large`, pragmatic-quantity comparisons). Under escalation, Phase 6b Theme/Tone critic is the primary catchment; under narrow proposals, this test is the only catchment. 11. **Action-Space Integrity (Rule 11)** — mechanical layer (`rule11_action_space`): if the CF introduces or depends on exceptional capability, the current-write record supplies at least three distinct ordinary- or mid-tier-actor leverage forms from the permissible enum. **Judgment layer**: each leverage entry names a concrete in-world mechanism rather than a generic assurance. If the CF does not introduce or depend on exceptional capability, PASS trivially with rationale. 12. **Redundancy (Rule 12)** — mechanical layer (`rule12_redundancy`): hard-canon core truths have at least two distinct trace registers or cite a canonized hidden-truth mechanism. **Judgment layer**: each register is tied to a specific in-world form. If the CF is not a hard-canon core truth, PASS trivially with rationale. 13. **Misrecognition probe addressed (FOUNDATIONS §Acceptance Tests #9)** — judgment only. The PA `body_markdown` Phase 0 sub-section either declares a misrecognition layer (with `truth_scope.diegetic_status` and at minimum one `epistemic_profile.distortion_vectors[]` or `knowledge_exclusions[]` entry on the new CF) OR states `misrecognition_probe: NONE` with a one-line rationale. Bare absence fails. 14. **OQ pressure scan completed** — judgment only. The PA `body_markdown` `# Phase 0–11 Analysis` → Phase 10 sub-section enumerates every `OQ-` record returned by the pre-flight context packet (or backfilled via `mcp__worldloom__list_records({record_type: 'open_question_record'})` if the packet under-covered) with one of `{UNCHANGED, PRESSURED, NEW, RESOLVED}` classifications. Frontmatter `open_questions_touched[]` matches the PRESSURED + NEW + RESOLVED subset (UNCHANGED items appear only in the Phase 10 sub-section, not the frontmatter). Bare absence of the enumeration FAILS regardless of whether the scan would have produced any non-UNCHANGED entries. 9. **HARD-GATE → Phase 15a submit.** Present the deliverable summary. **Scale discipline** — large deliveries (≥6 affected sections OR ≥4 modification_history ops OR ≥3 new MR entries) present in thematic chunks: (1) verdict + phase-cited justification; (2) new CF YAML + CH YAML; (3) modification_history ops summarized per CF; (4) section appends summarized per file; (5) MR firewall extensions / new MR entries; (6) PA file path. Chunking is for review legibility; the HARD-GATE fires on a SINGLE approval moment covering the entire deliverable. On user approval, persist the patch plan envelope as JSON (e.g., `/tmp/.json`), invoke the canonical signer to issue the `approval_token` (`node tools/world-mcp/dist/src/cli/sign-approval-token.js [--world-root ] ` — see `docs/HARD-GATE-DISCIPLINE.md` §Issuing a token), then call `mcp__worldloom__submit_patch_plan(plan, approval_token)` with the same envelope object and the issued token. **Submit-path selection by envelope size**: for envelopes >50KB (common for accept branches with many section updates, modification-history appends, or mystery/open-question records), submit via the CLI path instead: `node tools/world-mcp/dist/src/cli/submit-patch-plan.js [--world-root ] ` (persist the signed token to a text file first; redirect stdout to a file — e.g., `> /tmp/.receipt.json` — so the `PatchReceipt` is reviewable in one invocation, since re-invoking the submit just to inspect the receipt triggers `approval_replayed` per the failure-mode response below). The CLI path is functionally equivalent - same engine code, same `PatchReceipt`, same failure-mode codes - but bypasses MCP transport size constraints; see `docs/HARD-GATE-DISCIPLINE.md` §Validating and submitting the plan. Two-phase commit and engine-controlled write order replace the prior 25+ Edit-with-checkpoint discipline - partial-failure recovery is structural, not procedural. **Failure-mode response**: on `approval_expired`, re-sign (plan unchanged, hashes match) and resubmit; on `approval_replayed`, do NOT resubmit (the prior submit already applied). On `index_stale`, the engine detected that the world index has diverged from on-disk content, typically because a direct-`Edit` to hybrid-file frontmatter was not followed by an index sync. The response's `detail.divergent_files[].file_path` names the divergent files. Run `node tools/world-index/dist/src/cli.js sync ` to refresh the index, then resubmit the patch plan with the same approval token if it has not expired. On `validator_failed`, inspect `detail.verdicts[].location.file`: if the cited file is one of the records this patch plan is creating or extending (per `expected_id_allocations`, extension targets, or the PA/adjudication target), the schema violation is in this skill's output - fix and resubmit; **if the cited file is unrelated existing world state, pause and escalate to the user - this skill must not silently modify other canon-adjacent files. Hook 3 does not block hybrid-file frontmatter edits, so the discipline is prescriptive.** After any user-authorized direct-`Edit` to a hybrid-file frontmatter under `worlds//characters/`, `diegetic-artifacts/`, or `adjudications/` (the surfaces under `record_schema_compliance` validator scope), run `node tools/world-index/dist/src/cli.js sync ` before resubmitting - the validator runs against the indexed world state, not against on-disk content. INDEX.md edits do not require sync (not under validator scope). ## PA `body_markdown` Structure PA frontmatter is engine-validated against the SPEC-14 schema. The `body_markdown` payload of `append_adjudication_record` carries analysis prose and SHOULD include named sections in this order: `# Discovery` (top-of-file index mirroring the four `*_touched` frontmatter arrays for in-body grep); `# Proposal` (verbatim copy + user-stated constraints); `# Phase 0–11 Analysis` (full per-phase outputs, including required sub-heading `## Phase 0 — Proposal Normalization, Prior-Silence, and Misrecognition Probe` with `prior_silence:` acknowledgment / "not previously silent" rationale plus `misrecognition_probe:` layer-captured details OR `NONE` plus one-line rationale, and — when escalation fires per Procedure step 3 — a `### Phase 6b Multi-Critic Synthesis` sub-heading nested under `## Phase 6 — Consequence Propagation` documenting convergent findings, axis-(c) override decisions per Procedure step 6, and adopted-vs-not-adopted critic recommendations; this is the "Phase 6b Synthesis section" that Procedure step 6 references — distinct from the verbatim `# Critic Reports` section that follows); `# Phase 14a Validation Checklist` (14 tests with PASS/FAIL + one-line rationale); `# Verdict` + `# Justification` (phase-cited); `# Critic Reports` (verbatim, if escalation fired); `# Required World Updates Applied` (one-paragraph-per-section summary, accept only); `# Resubmission Menu` (REVISE) OR `# Why This Cannot Be Repaired` (REJECT); `# User Override` (if Phase 14b override fired). The Discovery-block `_touched` semantics (substantively-affected items only — items receiving extension blocks, firewall additions, mod_history entries, new entries, or pressured-deferral annotations; NOT items merely tested-and-found-compatible) is enforced for the frontmatter arrays by `record_schema_compliance`; body-markdown headings are free prose under those names. ## Guardrails - **Single world per invocation.** Never creates a new world (`create-base-world` does that), never modifies `docs/FOUNDATIONS.md`, never touches other worlds, never touches `archive/` or `brainstorming/`. - **Engine-only writes to `_source/`.** Direct `Edit`/`Write` on `_source//*.yaml` is blocked by Hook 3. Hybrid-file writes (PA, character, diegetic-artifact records) route through engine append ops; `WORLD_KERNEL.md` and `ONTOLOGY.md` are not in this skill's mutation surface. - **ID-collision abort.** If the engine pre-apply check rejects an allocated ID as colliding (concurrent or interrupted prior run), abort and ask the user to resolve before retrying. Never overwrite an existing record. - **Additive patches.** `append_extension` / `append_touched_by_cf` / `append_modification_history_entry` are append-only; structural-field rewrites require `update_record_field` with explicit retcon attestation. - **Sub-agent dispatch.** Critic sub-agents receive only the minimum slice (typically a role-scoped `get_context_packet`) — not the full world. Sub-agents never write files. - **HARD-GATE absoluteness.** Auto Mode does not relax the gate. - **No git commit from inside the skill.** Writes land in the working tree; the user reviews and commits. - **Worktree discipline.** All paths resolve from the worktree root if invoked inside a worktree. - **No diegetic artifacts.** This skill operates on canon claims; in-world texts belong to `diegetic-artifact-generation`. If the proposal is shaped like a diegetic text, normalize at Phase 0 or abort with a pointer. ## Inherited-Drift Handling If Phase 6b multi-critic synthesis OR inline-lens analysis flags pre-existing inconsistency inherited from prior CFs (counting drift, naming drift), resolve by counting/stating correctly in NEW prose only. Retroactive cleanup of pre-existing prose is out-of-scope and requires a separate retcon workflow. Log the inherited drift in the PA Justification section (or in the Critic Reports section when escalation fired). Silently correcting old prose violates Rule 6 even when factually right; perpetuating old drift squanders the chance to count honestly. ## Final Rule A canon fact is not added until it has a scope, a consequence web, an ordinary-life signature, a stabilizer against universalization, an attribution trail in every record it touches, and a Change Log Entry the world can be audited against — and once added, the ledger is append-only; the only way to change an accepted fact is another run of this skill that produces an explicit retcon entry with retcon attestation on the patch op.