@warpgogol/forge 1.2.2 → 2.2.0

package/profiles/phaser-turborepo.yaml

@@ -7,15 +7,18 @@ detect:
     - package.json
 workspace:
   dirs:
-    - games
+    - apps
     - packages
     - services
     - scripts
+    - tools
+    - missions
+    - systems-cache
   files:
     - path: pnpm-workspace.yaml
       content: |
         packages:
-          - "games/*"
+          - "apps/*"
           - "packages/*"
           - "services/*"
     - path: turbo.json
@@ -201,10 +204,143 @@ workspace:
         }
 
         console.log(`Cleaned ${toDelete.length} directories.`);
+    - path: tools/kernel.config.ts
+      content: |
+        import { defineKernelConfig } from "@warpgogol/werkstatt/kernel/types";
+        import { werkstattGamePlugin } from "@warpgogol/werkstatt-game";
+
+        export default defineKernelConfig({
+          name: "__PROJECT_NAME__",
+          description: "__PROJECT_NAME__ workshop",
+          moduleLoaders: {
+            "forge-core": async () => (await import("@warpgogol/forge/os/core")).forgeCoreModule,
+            "forge-rfc": async () => (await import("@warpgogol/forge/os/rfc-module")).forgeRfcModule,
+            "forge-adr": async () => (await import("@warpgogol/forge/os/adr-module")).forgeAdrModule,
+            "forge-plan": async () => (await import("@warpgogol/forge/os/plan-module")).forgePlanModule,
+            "forge-audit": async () => (await import("@warpgogol/forge/os/audit-module")).forgeAuditModule,
+            "forge-compass": async () => (await import("@warpgogol/forge/os/compass")).forgeCompassModule,
+            "forge-naming": async () => (await import("@warpgogol/forge/os/naming-module")).forgeNamingModule,
+            "forge-workflow": async () => (await import("@warpgogol/forge/os/workflow-module")).forgeWorkflowModule,
+            "forge-session": async () => (await import("@warpgogol/forge/os/session-module")).forgeSessionModule,
+            "forge-mission": async () => (await import("@warpgogol/forge/os/mission-module")).forgeMissionModule,
+            "forge-spec": async () => (await import("@warpgogol/forge/os/spec-module")).forgeSpecModule,
+            "forge-exploration": async () => (await import("@warpgogol/forge/os/exploration")).forgeExplorationModule,
+            "forge-program": async () => (await import("@warpgogol/forge/os/program")).forgeProgramModule,
+            "forge-werkstatt": async () => (await import("@warpgogol/forge/os/werkstatt")).forgeWerkstattModule,
+            mission: async () => (await import("@warpgogol/werkstatt/mission-module")).createMissionModule(),
+            sternsystem: async () => (await import("@warpgogol/werkstatt/sternsystem-module")).createSternsystemModule(),
+            bordbuch: async () => (await import("@warpgogol/werkstatt/bordbuch-module")).createBordbuchModule(),
+            "artifact-store": async () => (await import("@warpgogol/werkstatt/artifact-store-module")).createArtifactStoreModule(),
+            release: async () => (await import("@warpgogol/werkstatt/release-module")).createReleaseModule(),
+            leitstand: async () => (await import("@warpgogol/werkstatt/leitstand-module")).createLeitstandModule(),
+            notausgang: async () => (await import("@warpgogol/werkstatt/notausgang-module")).createNotausgangModule(),
+            evidence: async () => (await import("@warpgogol/werkstatt/evidence-module")).createEvidenceModule(),
+            "werkstatt-plugin": async () => (await import("@warpgogol/werkstatt/os/werkstatt-plugin-module")).forgeWerkstattPluginModule,
+            "werkstatt-autonomy": async () => (await import("@warpgogol/werkstatt/os/werkstatt-autonomy-module")).werkstattAutonomyModule,
+            "__PROJECT_NAME__-plugin": async () => werkstattGamePlugin,
+          },
+        });
+    - path: .npmrc
+      content: |
+        # @warpgogol scoped registry — replace YOUR_NPM_TOKEN with a valid npm read token
+        @warpgogol:registry=https://registry.npmjs.org/
+        //registry.npmjs.org/:_authToken=YOUR_NPM_TOKEN
+        # Auto-approve build scripts so operators aren't prompted during install
+        dangerously-allow-all-builds=true
+    - path: eslint.config.js
+      content: |
+        export default [
+          {
+            rules: {},
+          },
+        ];
+    - path: .prettierrc.mjs
+      content: |
+        export default {
+          semi: true,
+          singleQuote: false,
+          trailingComma: "all",
+          printWidth: 100,
+          tabWidth: 2,
+        };
+    - path: .gitattributes
+      content: |
+        # No LFS patterns for this stack
+    - path: hooks/pre-commit
+      content: |
+        #!/bin/sh
+        # Platform-scope pre-commit guard
+        # Runs werkstatt autonomy and plugin validation before commits
+        echo "Pre-commit: running platform checks..."
+        pnpm exec werkstatt run werkstatt.autonomy.validate || exit 1
+        pnpm exec werkstatt run werkstatt.plugin.validate || exit 1
+    - path: systems-cache/.gitkeep
+      content: |
+        # Sternsystem cache directory (RFC-0790)
+        # Per-system config and state files live in systems-cache/<id>/
+    - path: missions/.gitkeep
+      content: ""
+    - path: .forge/pinned.yaml
+      content: |
+        # Pinned foundation files (DNA-62, RFC-0733)
+        # Protect mode: warns on delete/move. Freeze mode: blocks modify too.
+        entries:
+          - path: tools/kernel.config.ts
+            mode: protect
+          - path: forge.yaml
+            mode: protect
+          - path: pnpm-workspace.yaml
+            mode: protect
+          - path: turbo.json
+            mode: protect
+          - path: tsconfig.base.json
+            mode: protect
+          - path: systems-cache/.gitkeep
+            mode: protect
+    - path: README.md
+      content: |
+        # __PROJECT_NAME__
+
+        A Warpgogol workshop powered by the Werkstatt engine and the @warpgogol/werkstatt-game plugin.
+
+        ## Prerequisites
+
+        - Node.js 24+
+        - pnpm 10+
+
+        ## Setup
+
+        ### 1. Configure npm token
+
+        This workshop depends on private @warpgogol packages. Edit `.npmrc` and replace `YOUR_NPM_TOKEN` with a valid npm read token:
+
+        ```sh
+        sed -i 's/YOUR_NPM_TOKEN/your_actual_token/' .npmrc
+        ```
+
+        ### 2. Install dependencies
+
+        ```sh
+        pnpm install
+        ```
+
+        ### 3. Verify the workshop
+
+        ```sh
+        pnpm exec werkstatt run forge.doctor
+        pnpm exec werkstatt run werkstatt.plugin.validate
+        pnpm exec werkstatt run werkstatt.autonomy.validate
+        ```
+
+        ## Stack
+
+        - Engine: @warpgogol/werkstatt
+        - Plugin: @warpgogol/werkstatt-game
+        - Stack profile: phaser-turborepo
 install:
   - pnpm add -D typescript turbo @warpgogol/forge @warpgogol/werkstatt @warpgogol/werkstatt-shared @warpgogol/werkstatt-game prettier
 firstWorkspace:
-  path: games/my-game
+  path: apps/my-game
   files:
     - path: package.json
       content: |

package/skills/_shared/fo-pipeline-conventions.md

@@ -164,6 +164,61 @@ When the operator says any session-end trigger phrase (e.g. "Завершаем
 
 The `fo-session-retro` skill IS the session-end protocol — it runs transcript save, temp cleanup, docs.archive, clean tree check, RFC verification, insight triage, and produces the closing block. Do not substitute it with a manual summary. The closing block comes from `fo-session-retro`, not from the agent directly.
 
+## Pre-pipeline checkpoint
+
+When a pipeline skill (`fo-idea-i-just-want-to-see-the-result`, `fo-idea-i-just-want-to-see-the-plan`, `fo-idea-implement`) is invoked after substantial pre-existing session context — discussion, code exploration, document creation, debugging — the agent performs a pre-pipeline checkpoint to release that context before the pipeline starts. The pipeline is self-sufficient: it reads the RFC/ADR, plan, AGENTS.md, and DNA invariants fresh. Pre-existing session context is no longer actionable once the pipeline begins.
+
+### When to emit
+
+Emit the pre-pipeline checkpoint when **both** conditions are met:
+
+1. **Pre-existing context exists** — the session has accumulated context from prior work (discussion, file reads, search results, document creation, debugging). If the skill is invoked at the start of a session with no prior context, skip the checkpoint — there is nothing to release.
+2. **The skill runs a pipeline** — `fo-idea-i-just-want-to-see-the-result` (full or `stopAfter: plan`), `fo-idea-i-just-want-to-see-the-plan`, or `fo-idea-implement`. Skills that perform a single action (e.g. `fo-idea-audit`, `fo-idea-enhance`) do not need this checkpoint.
+
+**Double-checkpoint guard:** If a pre-pipeline checkpoint was already emitted by a calling orchestrator (e.g. `fo-idea-i-just-want-to-see-the-result` emitted one, then invoked `fo-idea-implement`), the called skill MUST skip its own checkpoint — the context was already released. Scan conversation output for an existing `checkpoint: pre-pipeline` block before emitting a new one.
+
+**Wrapper skills:** `fo-idea-i-just-want-to-see-the-plan` delegates to `fo-idea-i-just-want-to-see-the-result` and does not emit its own checkpoint — the orchestrator handles it.
+
+### How to emit
+
+1. **Emit pre-pipeline checkpoint block** — output a YAML-formatted block in conversation output with the following fields:
+
+```yaml
+---
+checkpoint: pre-pipeline
+documents:
+  - id: RFC-XXXX
+    type: RFC
+    status: accepted
+operatorConstraints:
+  - "explicit constraints from the operator not captured in the document"
+aiLanguage: uk
+sessionSummary: >
+  1-3 sentences capturing key decisions, edge cases, and mental models
+  from the pre-pipeline discussion that are not in the document text.
+---
+```
+
+2. **Preserve critical fields** — the following must survive the context release:
+   - `documents` — id, type, and status of each document to process (needed by the pipeline's step 0 detection)
+   - `operatorConstraints` — explicit constraints or preferences the operator stated in conversation that are not written into the RFC/ADR (e.g. "don't touch packages/foo", "use approach Y"). Empty if none.
+   - `aiLanguage` — the operator's AI language preference (to avoid re-reading `PREFERENCES.md`)
+   - `sessionSummary` — 1-3 freeform sentences capturing key decisions, edge cases, and mental models from the discussion. This mitigates the session-affinity risk: the `fo-idea-implement` skill warns that "session context contains edge cases and mental models not fully captured in the plan text." The summary preserves the most important ones.
+
+3. **Release pre-existing context** — explicitly treat all detailed context from before the checkpoint as no longer actionable: discussion text, codebase search results, file reads, edit operations, intermediate reasoning, debug output. Retain only the checkpoint block and `PREFERENCES.md` settings.
+
+4. **Fresh start** — begin the pipeline with a fresh read phase: re-read the RFC/ADR file and all related documents (amends, supersedes, related RFCs, DNA invariants, AGENTS.md sections).
+
+### What NOT to release
+
+- **`PREFERENCES.md` settings** — `aiLanguage`, `documentationLanguage`, and other preferences remain active.
+- **The checkpoint block itself** — it is the resume marker and the only link to pre-pipeline context.
+- **Operator constraints** — if the operator said "don't touch X" or "use approach Y" in conversation, these must be respected throughout the pipeline.
+
+### Resume behavior
+
+When resuming an interrupted session, scan conversation output for the last pre-pipeline checkpoint block. If found, extract `documents`, `operatorConstraints`, `aiLanguage`, and `sessionSummary` to restore the pre-pipeline context without re-reading the full conversation history. Then proceed with the pipeline's own resume logic (detecting completed steps via git log, file inspection, frontmatter status).
+
 ## Context checkpoint between batch items
 
 When the orchestrator skill processes multiple documents (>=2), perform a context checkpoint after completing one document and before starting the next:

package/skills/fo/fo-doc-audit/SKILL.md

@@ -249,8 +249,8 @@ Skills that delegate to `fo-doc-audit`:
 
 - **`fo-fix`** step 5 ("Documentation audit") — invokes `fo-doc-audit`.
 - **`fo-fix`** merge conflict resolution step 4 ("Documentation audit") — invokes `fo-doc-audit`.
-- **`fo-idea-implement`** step 3.9 ("Documentation audit") — invokes `fo-doc-audit`.
-- **`fo-idea-implement`** ADR-FLOW step 4.6 ("Documentation audit") — invokes `fo-doc-audit`.
+- **`fo-idea-implement`** step 4.9 ("Documentation audit") — invokes `fo-doc-audit`.
+- **`fo-idea-implement`** ADR-FLOW step 5.6 ("Documentation audit") — invokes `fo-doc-audit`.
 
 ## Constraints
 

package/skills/fo/fo-idea-i-just-want-to-see-the-plan/SKILL.md

@@ -19,6 +19,8 @@ See `_shared/fo-pipeline-conventions.md` §Language policy.
 
 Thin wrapper around `fo-idea-i-just-want-to-see-the-result`. Invokes the orchestrator with `stopAfter: plan`, which runs steps 0–3 only (idea → audit → enhance → plan). Step 4 (implement, which includes review and fix) is not run.
 
+The orchestrator handles the pre-pipeline checkpoint per `_shared/fo-pipeline-conventions.md` §Pre-pipeline checkpoint — no separate checkpoint is needed in this wrapper.
+
 ## ADR documents
 
 ADRs skip audit, enhance, and plan. The orchestrator stops after step 0 (idea creation) with the message: "ADR does not require a plan. Run `/fo-idea-implement` to implement."

package/skills/fo/fo-idea-i-just-want-to-see-the-result/SKILL.md

@@ -50,7 +50,11 @@ Determine whether the operator provided a raw idea or a document id:
 
 Record the document id(s) and type(s) (RFC or ADR). If multiple documents were created in a series, process them in dependency order — the same order `fo-idea` created them.
 
-### 1. Run the pipeline
+### 1. Pre-pipeline checkpoint
+
+Before starting the pipeline, perform a pre-pipeline checkpoint per `_shared/fo-pipeline-conventions.md` §Pre-pipeline checkpoint. If pre-existing session context exists (discussion, document creation, debugging), emit the checkpoint block, release pre-existing context, and start the pipeline with a fresh read phase. If the session has no prior context, skip the checkpoint.
+
+### 2. Run the pipeline
 
 For each document, run the full pipeline inline. The pipeline differs for RFCs and ADRs.
 
@@ -120,7 +124,7 @@ Do not invoke `fo-review` or `fo-fix` separately — they are built into `fo-ide
 
 This fallback ensures review and fix are never skipped, even if `fo-idea-implement` failed to execute them internally.
 
-### 2. Report and stop
+### 3. Report and stop
 
 After the pipeline is complete (or if it was interrupted and resumed), present a single summary in `aiLanguage`. **Translate all labels and headings to `aiLanguage`** — the template below is structural only. Only identifiers (RFC-XXXX, ADR-XXXX, file paths) stay untranslated.
 
@@ -142,7 +146,7 @@ If multiple documents were processed, present one summary block per document.
 
 **Stop.** Do not invoke `/grilling` or any other skill after the pipeline is complete. The operator asked to "just see the result" — the result is the summary above.
 
-### 3. Resume if interrupted
+### 4. Resume if interrupted
 
 If the session was interrupted (agent stopped, context limit, crash, checkpoint summary) and the operator re-invokes this skill or continues the session:
 

package/skills/fo/fo-idea-implement/SKILL.md

@@ -41,15 +41,19 @@ Determine the document type by:
 
 If the type cannot be determined, ask the user.
 
-### 3. RFC implementation flow
+### 3. Pre-pipeline checkpoint
 
-#### 3.1. Prerequisite checks (per RFC)
+Before starting implementation, perform a pre-pipeline checkpoint per `_shared/fo-pipeline-conventions.md` §Pre-pipeline checkpoint. If pre-existing session context exists (discussion, document creation, debugging, prior pipeline steps), emit the checkpoint block, release pre-existing context, and start implementation with a fresh read phase. If the session has no prior context (e.g. this skill was invoked at the start of a session), skip the checkpoint. If a pre-pipeline checkpoint was already emitted by a calling orchestrator (e.g. `fo-idea-i-just-want-to-see-the-result`), skip this step — the checkpoint was already done.
+
+### 4. RFC implementation flow
+
+#### 4.1. Prerequisite checks (per RFC)
 
 The pipeline is: create → audit → enhance → plan → implement. Audit, enhance, and a plan are **mandatory** — no RFC may proceed to implementation without all three being completed. The RFC must also be `accepted` — this skill does not transition `draft` to `accepted`; that is the responsibility of `fo-idea-plan`.
 
 Before running the implementation on each RFC, perform these checks **in order**. If any check fails, record the RFC as **skipped** in the batch summary with the reason, and immediately proceed to the next RFC in the batch. Do not stop the entire batch — skip and report.
 
-1. **Prefix check** — if the id starts with `ADR-`, this is not an RFC. Skip with message: `ADR-XXXX is an ADR, not an RFC. Use the ADR implementation flow (step 4 below) for ADR-XXXX.`
+1. **Prefix check** — if the id starts with `ADR-`, this is not an RFC. Skip with message: `ADR-XXXX is an ADR, not an RFC. Use the ADR implementation flow (step 5 below) for ADR-XXXX.`
 2. **RFC file exists** — look for `docs/rfcs/rfc-XXXX-*.md`. If no file is found, skip with message: `RFC-XXXX not found in docs/rfcs/. Run /fo-idea-create-rfc first.`
 3. **Terminal status check** — read the RFC's `status` frontmatter. If the status is `implemented`, skip with message: `RFC-XXXX is already implemented. Nothing to do.` If the status is `rejected` or `superseded`, skip with message: `RFC-XXXX is <status> (terminal). Terminal RFCs cannot be implemented. To change this decision, create a new RFC with supersedes: [RFC-XXXX] via /fo-idea-create-rfc.`
 4. **Audit check** — look for `docs/audits/audit-rfc-XXXX-*.md`. If no audit file exists, skip with message: `No audit report found for RFC-XXXX in docs/audits/. Run /fo-idea-audit RFC-XXXX first. The pipeline is: create → audit → enhance → plan → implement.`
@@ -57,15 +61,15 @@ Before running the implementation on each RFC, perform these checks **in order**
 6. **Accepted status check** — if the status is not `accepted` (e.g. `draft` or `reviewing`), skip with message: `RFC-XXXX is <status>, not accepted. Run /fo-idea-plan RFC-XXXX first — it will transition the RFC to accepted and create the plan. The pipeline is: create → audit → enhance → plan → implement.`
 7. **Plan check** — look for `docs/plans/plan-rfc-XXXX-*.md`. If no plan file exists, skip with message: `No plan file found for RFC-XXXX in docs/plans/. Run /fo-idea-plan RFC-XXXX first. The pipeline is: create → audit → enhance → plan → implement.`
 
-If all checks pass, proceed to step 3.2.
+If all checks pass, proceed to step 4.2.
 
-#### 3.2. Read the RFC and related context
+#### 4.2. Read the RFC and related context
 
 Read the RFC fully and all RFCs listed in its `amends[]`, `related[]`, and `supersedes[]`. Read the plan fully. Read the closest `AGENTS.md` for each impacted package. Read `ref(forge.yaml bindings.paths.invariantsFile)` entries for every DNA invariant in `satisfies[]`.
 
 If the plan or RFC has genuine ambiguities that would cause wrong implementation, ask the user **before starting implementation**. Use `ask_user_question` with a recommended option first. Once implementation begins, stop asking — make autonomous decisions.
 
-#### 3.3. Implement step by step
+#### 4.3. Implement step by step
 
 Execute the plan's step sequence in order. For each step:
 
@@ -96,7 +100,7 @@ Stage only the files touched by this step. Do not stage unrelated changes — an
 - **Compass scaffolding.** New non-trivial source files in `apps/` or `packages/` must carry `MODULE_CONTRACT` and `CHANGE_SUMMARY` scaffolding. Check the project's invariants file for the canonical Compass markup rule.
 - **Compass terminology.** Use Compass (not GRACE) in all new code, documentation, and log messages.
 
-#### 3.4. Run heavy checks
+#### 4.4. Run heavy checks
 
 After **all** plan steps are complete, run the heavy validation suite in order:
 
@@ -122,9 +126,9 @@ Use the `packagesImpacted` and `appsImpacted` frontmatter lists to determine whi
 
 **Do not run a full root `root build` or `turbo run build`.** The success criterion is that all impacted workspaces pass their scoped checks, not that the entire ecosystem builds. See root AGENTS.md §Build verification discipline.
 
-#### 3.5. Fix errors
+#### 4.5. Fix errors
 
-If any check in step 3.4 fails, fix every error:
+If any check in step 4.4 fails, fix every error:
 
 1. Read the error output.
 2. Identify the root cause.
@@ -142,7 +146,7 @@ If any check in step 3.4 fails, fix every error:
 
 Continue until all impacted checks pass.
 
-#### 3.6. Check acceptance criteria
+#### 4.6. Check acceptance criteria
 
 Read the RFC's `## Acceptance criteria` section. For each checkbox:
 
@@ -153,9 +157,9 @@ Read the RFC's `## Acceptance criteria` section. For each checkbox:
 5. **If a criterion cannot be met** (e.g., requires an external dependency not yet available, requires a pilot that is not registered), do NOT mark it `[x]` and do NOT stamp `implemented`. Instead, split the deferred work into a follow-up RFC via `rfc.supersede.propose`. An RFC with unchecked `[ ]` criteria cannot transition to `implemented` — this is enforced by V-26.
 6. **Ensure `reviewers` is non-empty** — `rfc.validate` enforces V-25: implemented RFCs with an empty `reviewers` field fail validation. Add at least one reviewer (e.g. `human:<name>`) before stamping `implemented`.
 
-Do not proceed to step 3.7 until every acceptance criterion checkbox is checked with evidence.
+Do not proceed to step 4.7 until every acceptance criterion checkbox is checked with evidence.
 
-#### 3.7. Run acceptance probes and emit evidence
+#### 4.7. Run acceptance probes and emit evidence
 
 If the RFC declares `acceptance:` probes in frontmatter:
 
@@ -181,7 +185,7 @@ Emit per-RFC verification evidence for RFC-XXXX implementation.
 
 Stage `docs/rfcs/verification/rfc-xxxx.generated.json`.
 
-#### 3.8. Stamp implemented
+#### 4.8. Stamp implemented
 
 Transition the RFC to `implemented` using the `rfc.implement.stamp` command. Direct edits to `status`, `implementedAt`, and `updatedAt` are prohibited for all actors.
 
@@ -208,7 +212,7 @@ Transition the RFC to `implemented` using the `rfc.implement.stamp` command. Dir
 
    Stage only the RFC file. The implementation commit and the stamp commit MUST be separate.
 
-#### 3.8b. Regenerate command manifest (MANDATORY)
+#### 4.8b. Regenerate command manifest (MANDATORY)
 
 If the RFC added, changed, or removed commands (check `commands.added`, `commands.changed`, `commands.removed` in the RFC frontmatter), regenerate the command manifest so that `rfc.validate` does not report `RFC-CMD-02` (command listed but not registered):
 
@@ -228,26 +232,26 @@ If the RFC has no `commands.*` changes (e.g. it only changes schemas, docs, or i
 
 This step is MANDATORY for any RFC with `commands.added`, `commands.changed`, or `commands.removed`. A stale manifest causes `RFC-CMD-02` violations that block `rfc.validate` for all implemented RFCs.
 
-#### 3.9. Documentation audit (fo-doc-audit)
+#### 4.9. Documentation audit (fo-doc-audit)
 
 After implementation is complete and all checks pass, invoke `fo-doc-audit` via the `skill` tool. It analyzes the session's changes, checks all documentation surfaces (AGENTS.md, README, Compass XML, architecture-dna.md, templates, generated artifacts, COMMANDS.md/PACKAGE_GRAPH.md), applies needed updates, and commits them separately. Wait for it to complete.
 
 If `fo-doc-audit` reports that no updates are needed, proceed to the next step.
 
-#### 3.10. Code review (fo-review)
+#### 4.10. Code review (fo-review)
 
 After the documentation audit, invoke `fo-review` via the `skill` tool. It performs a cross-session fitness check of the code diff against Forge standards (DNA, forward-only, Compass, agent clarity, pragmatism). The review covers all code changes made in this session since the first implementation commit.
 
 1. Determine the diff range: `git diff <merge-base-of-session>...HEAD` — where merge-base is the commit before the first `implement:` commit for this RFC.
 2. Invoke `fo-review` with the diff range. Wait for it to complete (persist + commit the review report in `docs/reviews/code/`).
-3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 3.12.
-4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 3.11 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding, including ones labelled "minor" or "cosmetic".
+3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 4.12.
+4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 4.11 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding, including ones labelled "minor" or "cosmetic".
 
 **This step is MANDATORY.** Do not skip it, even if the implementation seems clean. The review is the quality gate that catches DNA misalignment, forward-only violations, Compass drift, and agent clarity issues that implementation authors miss.
 
-#### 3.11. Fix review findings (fo-fix)
+#### 4.11. Fix review findings (fo-fix)
 
-If `fo-review` (step 3.10) reported **any** findings (even cosmetic ones on axes A/C/F/G), invoke `fo-fix` via the `skill` tool. It applies the review findings iteratively: fix → typecheck → commit → re-check.
+If `fo-review` (step 4.10) reported **any** findings (even cosmetic ones on axes A/C/F/G), invoke `fo-fix` via the `skill` tool. It applies the review findings iteratively: fix → typecheck → commit → re-check.
 
 1. Invoke `fo-fix` with the review report. Wait for it to complete.
 2. After `fo-fix` returns, re-run `fo-review` to confirm all findings are resolved.
@@ -256,18 +260,18 @@ If `fo-review` (step 3.10) reported **any** findings (even cosmetic ones on axes
 
 If `fo-review` reported truly zero findings (the report explicitly states "No issues." on every axis), skip this step. An `approved` verdict with any finding text on any axis does NOT qualify as zero findings.
 
-#### 3.11b. Implementation status gate (RFC)
+#### 4.11b. Implementation status gate (RFC)
 
 Before reporting completion, verify the RFC has been stamped as `implemented`:
 
 1. Read the RFC frontmatter — confirm `status: implemented` and `implementedAt` is set.
 2. Run `ref(forge.yaml bindings.commands.validateRfc) --id RFC-XXXX --json` — confirm zero errors.
-3. If status is not `implemented`, go back to step 3.8 (Stamp implemented) and run the stamp command.
+3. If status is not `implemented`, go back to step 4.8 (Stamp implemented) and run the stamp command.
 4. If `rfc.validate` reports errors, fix them before proceeding.
 
-This gate is MANDATORY. Do not proceed to step 3.12 (report) until the RFC is `implemented`.
+This gate is MANDATORY. Do not proceed to step 4.12 (report) until the RFC is `implemented`.
 
-#### 3.12. RFC report
+#### 4.12. RFC report
 
 After implementation is complete, report in `aiLanguage`. **Translate all labels and headings to `aiLanguage`** — the template below is structural only. Only identifiers (RFC-XXXX, file paths, skill names) stay untranslated.
 
@@ -284,11 +288,11 @@ After implementation is complete, report in `aiLanguage`. **Translate all labels
 ### Status: implemented (<date>)
 ```
 
-### 4. ADR implementation flow
+### 5. ADR implementation flow
 
 Execute this flow when the document is an ADR (prefix `ADR-`, or file in `docs/adrs/`).
 
-#### 4.1. Read the ADR
+#### 5.1. Read the ADR
 
 Read the ADR file. Extract:
 
@@ -298,7 +302,7 @@ Read the ADR file. Extract:
 - **Consequences** — what the decision implies for the codebase.
 - **Related** — any RFCs, ADRs, or DNA invariants referenced.
 
-#### 4.2. Transition to accepted (if needed)
+#### 5.2. Transition to accepted (if needed)
 
 If the ADR is `proposed` or `reviewing`, transition it to `accepted`:
 
@@ -317,7 +321,7 @@ If the ADR is `proposed` or `reviewing`, transition it to `accepted`:
 
 If the ADR is already `accepted`, proceed directly.
 
-#### 4.3. Implement the decision
+#### 5.3. Implement the decision
 
 Read the `## Decision` section and implement it in code. **For each decision point, verify whether the code already exists** — ADRs may declare fields or extensions that related RFCs did not fully implement. Do not assume associated RFCs covered everything; check each decision against the actual codebase and implement any gaps. Follow the same principles as RFC implementation:
 
@@ -335,7 +339,7 @@ Read the `## Decision` section and implement it in code. **For each decision poi
 
 - If a tool call fails with a recoverable error, recover autonomously: split content, use `edit`/`multi_edit`, decompose files, and retry immediately.
 
-#### 4.4. Run scoped build checks
+#### 5.4. Run scoped build checks
 
 After implementation is complete, run heavy checks for the impacted workspaces only:
 
@@ -359,7 +363,7 @@ After implementation is complete, run heavy checks for the impacted workspaces o
 
    **MUST NOT run a full root `root build` or `turbo run build`.** Only check the workspaces this ADR touches. See root AGENTS.md §Build verification discipline.
 
-#### 4.5. Fix errors
+#### 5.5. Fix errors
 
 If any check fails, fix every error:
 
@@ -377,26 +381,26 @@ If any check fails, fix every error:
 
 Continue until all impacted checks pass.
 
-#### 4.6. Documentation audit (fo-doc-audit)
+#### 5.6. Documentation audit (fo-doc-audit)
 
 After implementation is complete and all checks pass, invoke `fo-doc-audit` via the `skill` tool. It analyzes the session's changes, checks all documentation surfaces, applies needed updates, and commits them separately. Wait for it to complete.
 
 If `fo-doc-audit` reports that no updates are needed, proceed to the next step.
 
-#### 4.7. Code review (fo-review)
+#### 5.7. Code review (fo-review)
 
 After the documentation audit, invoke `fo-review` via the `skill` tool. It performs a cross-session fitness check of the code diff against Forge standards. The review covers all code changes made in this session.
 
 1. Determine the diff range: `git diff <merge-base-of-session>...HEAD`.
 2. Invoke `fo-review` with the diff range. Wait for it to complete (persist + commit the review report).
-3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 4.9.
-4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 4.8 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding.
+3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 5.9.
+4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 5.8 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding.
 
 **This step is MANDATORY.** Do not skip it.
 
-#### 4.8. Fix review findings (fo-fix)
+#### 5.8. Fix review findings (fo-fix)
 
-If `fo-review` (step 4.7) reported **any** findings (even cosmetic ones), invoke `fo-fix` via the `skill` tool.
+If `fo-review` (step 5.7) reported **any** findings (even cosmetic ones), invoke `fo-fix` via the `skill` tool.
 
 1. Invoke `fo-fix` with the review report. Wait for it to complete.
 2. After `fo-fix` returns, re-run `fo-review` to confirm all findings are resolved.
@@ -405,7 +409,7 @@ If `fo-review` (step 4.7) reported **any** findings (even cosmetic ones), invoke
 
 If `fo-review` reported truly zero findings (the report explicitly states "No issues." on every axis), skip this step. An `approved` verdict with any finding text on any axis does NOT qualify as zero findings.
 
-#### 4.9. ADR code-trace
+#### 5.9. ADR code-trace
 
 Before stamping `implemented`, verify that the ADR is mentioned in the codebase — this leaves a trace linking code back to the decision record, just as RFCs leave traces.
 
@@ -413,7 +417,7 @@ Before stamping `implemented`, verify that the ADR is mentioned in the codebase
    - **COMPASS block comments** — `MODULE_CONTRACT`, `CHANGE_SUMMARY`, or other Compass scaffolding comments that reference the ADR id.
    - **Inline code mentions** — comments, docstrings, or annotations in source files that reference the ADR id.
 
-2. **If mentions are found** — the trace exists. Proceed to step 4.10.
+2. **If mentions are found** — the trace exists. Proceed to step 5.10.
 
 3. **If no mentions are found** — attempt to find the most relevant file(s) where the decision was implemented. If the file(s) can be identified:
    - Add a Compass block comment referencing the ADR id to the file's `MODULE_CONTRACT` or `CHANGE_SUMMARY` section. For example: `<item>ADR-XXXX: <brief note on what this ADR decided for this module.</item>`
@@ -426,13 +430,13 @@ Before stamping `implemented`, verify that the ADR is mentioned in the codebase
      Add ADR-XXXX reference to <file> to link the decision to the code.
      ```
 
-   - Proceed to step 4.10.
+   - Proceed to step 5.10.
 
 4. **If the relevant file(s) cannot be identified** — ask the operator: `ADR-XXXX was implemented but no code mention was found. Please point to the file(s) where this ADR's decision was applied so I can add a trace reference.` After the operator provides the file(s), add the trace as described in step 3, commit, and proceed.
 
 **For already-implemented ADRs** (if this step is reached for an ADR that was already `implemented`): this check is informational — attempt to find the trace and add it if missing, but do not block on it.
 
-#### 4.10. Stamp implemented
+#### 5.10. Stamp implemented
 
 After all checks pass and documentation is updated, transition the ADR to `implemented` using `adr.implement.stamp` as required by the ADR lifecycle contract. Direct edits to ADR `status`, `implementedAt`, and `updatedAt` are prohibited — use the stamp command instead.
 
@@ -456,18 +460,18 @@ After all checks pass and documentation is updated, transition the ADR to `imple
 
    Stage only the ADR file. The implementation commit and the stamp commit MUST be separate.
 
-#### 4.10b. Implementation status gate (ADR)
+#### 5.10b. Implementation status gate (ADR)
 
 Before reporting completion, verify the ADR has been transitioned to `implemented`:
 
 1. Read the ADR frontmatter — confirm `status: implemented` and `implementedAt` is set.
 2. Run `ref(forge.yaml bindings.commands.validateAdr) --id ADR-XXXX --json` — confirm zero errors.
-3. If status is not `implemented`, go back to step 4.10 (Stamp implemented) and run `adr.implement.stamp`.
+3. If status is not `implemented`, go back to step 5.10 (Stamp implemented) and run `adr.implement.stamp`.
 4. If `adr.validate` reports errors, fix them before proceeding.
 
-This gate is MANDATORY. Do not proceed to step 4.11 (report) until the ADR is `implemented`.
+This gate is MANDATORY. Do not proceed to step 5.11 (report) until the ADR is `implemented`.
 
-#### 4.11. Report
+#### 5.11. Report
 
 After implementation is complete, report in `aiLanguage`. **Translate all labels and headings to `aiLanguage`** — the template below is structural only.
 
@@ -482,7 +486,7 @@ After implementation is complete, report in `aiLanguage`. **Translate all labels
 ### Status: implemented (<date>)
 ```
 
-### 5. Batch summary
+### 6. Batch summary
 
 If multiple documents were processed, present a single batch summary at the very end in `aiLanguage`. **Translate all labels, headings, and column names to `aiLanguage`** — the template below is structural only.
 
@@ -518,5 +522,5 @@ When an RFC was planned in this session, prefer implementing it in this session
 - **Do not weaken DNA invariants.** If implementation reveals an invariant conflict, escalate via `rfc.supersede.propose` instead of working around it.
 - **Compass scaffolding on new files.** Non-trivial new source files in `apps/` or `packages/` must carry `MODULE_CONTRACT` and `CHANGE_SUMMARY`. Check the project's invariants file for the canonical Compass markup rule.
 - **Compass terminology, not GRACE.** Use Compass in all new code, docs, and log messages.
-- **Review and fix are MANDATORY.** After implementation and doc-audit, always run `fo-review` (step 3.10 / 4.7) and `fo-fix` (step 3.11 / 4.8) if **any** findings exist in the review report — including cosmetic or minor findings. Do not stamp `implemented` without a review report in `docs/reviews/code/`. An `approved` verdict does NOT mean "skip fix" — read every axis section and count every finding. This is the quality gate that catches DNA misalignment, forward-only violations, and Compass drift.
+- **Review and fix are MANDATORY.** After implementation and doc-audit, always run `fo-review` (step 4.10 / 5.7) and `fo-fix` (step 4.11 / 5.8) if **any** findings exist in the review report — including cosmetic or minor findings. Do not stamp `implemented` without a review report in `docs/reviews/code/`. An `approved` verdict does NOT mean "skip fix" — read every axis section and count every finding. This is the quality gate that catches DNA misalignment, forward-only violations, and Compass drift.
 - **No `draft → accepted` transition for RFCs.** This skill requires RFC `status: accepted` and does not transition RFCs. Use `/fo-idea-plan` for that transition.

package/skills/fo/fo-session-retro/SKILL.md

@@ -178,10 +178,10 @@ For each identified RFC, read the frontmatter `status` field from `docs/rfcs/rfc
 
   | Option | Description |
   | --- | --- |
-  | Complete now | The agent proceeds to finish the remaining `fo-idea-implement` steps (3.6–3.8: check acceptance criteria with evidence, stamp implemented). This may require running validators, fixing errors, and committing the stamp. |
+  | Complete now | The agent proceeds to finish the remaining `fo-idea-implement` steps (4.6–4.8: check acceptance criteria with evidence, stamp implemented). This may require running validators, fixing errors, and committing the stamp. |
   | Leave as-is | The operator explicitly acknowledges the RFC remains in its current non-terminal status with unchecked acceptance criteria. No further action is taken on the RFC. |
 
-  If the operator chooses "Complete now", execute `fo-idea-implement` steps 3.6–3.8 for that RFC before proceeding. If multiple RFCs are in this state, ask about each one (or present them as a batch with `allowMultiple: true`).
+  If the operator chooses "Complete now", execute `fo-idea-implement` steps 4.6–4.8 for that RFC before proceeding. If multiple RFCs are in this state, ask about each one (or present them as a batch with `allowMultiple: true`).
 
 **4d. Report:**
 

package/src/onboarding/templates/behavioral-layer-core.md

@@ -76,7 +76,7 @@ The agent updates `.agents/operator-profile.md` immediately when the operator ex
 The current register is **{{register}}**.
 
 - **Business register:** core behavioral layer only — professional, efficient communication.
-- **Creative register:** core + extended behavioral layer (RFC-0549) — creative partnership, emotional support, companion mode.
+- **Creative register:** core + extended behavioral layer — creative partnership, emotional support, companion mode.
 - The register can be changed at any time via live operator feedback. The change takes effect immediately.
 
 ### Pushback policy
@@ -110,7 +110,7 @@ The agent handles performance, accessibility, SEO, and optimization automaticall
 
 ### First creation moment
 
-The first creation moment is special — the agent celebrates the operator's first creation and sets a welcoming tone. See RFC-0547 for the first-creation-moment protocol.
+The first creation moment is special — the agent celebrates the operator's first creation and sets a welcoming tone.
 
 ### Creative health and time awareness
 
@@ -152,8 +152,7 @@ Everything the operator creates belongs to them. The agent makes ownership expli
 In the creative register, the agent commits all changes automatically after each completed logical step (e.g. after implementing a feature, after fixing a bug, after creating a file). The operator is never asked about git, commits, or version control. No dirty files remain at any pause point. In the business register, the agent asks before committing.
 
 - **Auto-commit does not skip verification** — the agent still runs typecheck/build before committing. Auto-commit means the agent does not ask for permission, not that it skips quality checks.
-- **Auto-commit does not fire in companion mode** (RFC-0549) — companion mode is pure creative exploration without code changes, so there is nothing to commit.
-- **Auto-commit applies to forge projects** (bootstrapped projects using `forge create`). It does not affect Warpgogol mission workpiece commits, which use `mission.git.commit` per the mission lifecycle.
-- **RFC implementation preserves separate commits** — the separate implementation commit and RFC stamp commit pattern is preserved. Auto-commit fires after the implementation step, and the stamp is a separate commit.
+- **Auto-commit does not fire in companion mode** — companion mode is pure creative exploration without code changes, so there is nothing to commit.
+- **Auto-commit applies to forge projects** (bootstrapped projects using `forge create`).
 
 {{extendedLayer}}<!-- forge:end behavioral-layer -->