@jstn-sdk/rcs 0.1.0 → 0.1.6

package/docs/index.html

@@ -22,11 +22,56 @@
       <section class="hero">
         <span class="badge">Roblox Creator Skills</span>
         <h1>RCS</h1>
-        <p>Creator workflow runtime for OpenAI Codex CLI.</p>
+        <p>Roblox Studio workflow and runtime layer for OpenAI Codex CLI.</p>
         <pre><code>npm install -g @openai/codex @jstn-sdk/rcs</code></pre>
+        <p>RCS gives advanced Roblox creators one disciplined path from creator brief to approved blueprint to verified implementation, using Roblox-native terms instead of generic web-app workflow language.</p>
         <p>Real global version bumps now print an explicit reminder instead of auto-launching <code>rcs setup</code>. When you're ready, run <code>rcs setup</code> manually or use <code>rcs update</code> to check npm and then run the same setup refresh path. Fresh RCS-managed <code>gpt-5.5</code> configs recommend <code>250000 / 200000</code> only when those keys are missing.</p>
       </section>
 
+      <section aria-labelledby="who-its-for">
+        <h2 id="who-its-for">Who It's For</h2>
+        <div class="grid">
+          <article class="card">
+            <h3>Roblox Studio Builders</h3>
+            <p>Creators building gameplay systems, UI, remotes, persistence, live-ops, and technical experience code.</p>
+          </article>
+          <article class="card">
+            <h3>Plugin and Tool Authors</h3>
+            <p>Developers working on Studio-adjacent tooling who want Codex guided by Roblox-native workflow boundaries.</p>
+          </article>
+          <article class="card">
+            <h3>Advanced Codex Users</h3>
+            <p>People who already like Codex but want a stricter creator runtime instead of generic coding prompts.</p>
+          </article>
+          <article class="card">
+            <h3>Not the Main Audience</h3>
+            <p>RCS is not primarily a beginner teaching app, a generic web stack, or a SaaS product framework.</p>
+          </article>
+        </div>
+      </section>
+
+      <section aria-labelledby="how-it-works">
+        <h2 id="how-it-works">How It Works</h2>
+        <div class="grid">
+          <article class="card">
+            <h3>1. Brief</h3>
+            <p>Use <code>$brief</code> to clarify creator intent, scope, audience, and non-goals before implementation starts.</p>
+          </article>
+          <article class="card">
+            <h3>2. Blueprint</h3>
+            <p>Use <code>$blueprint</code> to approve the implementation shape, Roblox touchpoints, tradeoffs, and verification plan.</p>
+          </article>
+          <article class="card">
+            <h3>3. Forge or Crew</h3>
+            <p>Use <code>$forge</code> for one persistent owner or <code>$crew</code> for coordinated parallel execution.</p>
+          </article>
+          <article class="card">
+            <h3>4. Verify</h3>
+            <p>RCS keeps runtime state, contracts, and checks aligned so the work ends with actual proof, not vague confidence.</p>
+          </article>
+        </div>
+      </section>
+
       <section aria-labelledby="whats-new-010">
         <h2 id="whats-new-010">What's New in v0.1.0</h2>
         <div class="grid">
@@ -61,7 +106,7 @@
       <div class="grid">
         <article class="card"><h3>Agent Prompts</h3><p>Specialized roles for implementation, review, design, and planning.</p></article>
         <article class="card"><h3>Skills</h3><p>Composable creator workflows for briefing, blueprinting, forging, psychology design, setup, and tracing.</p></article>
-        <article class="card"><h3>Team Orchestration</h3><p>Staged execution pipeline with verification and fix loops.</p></article>
+        <article class="card"><h3>Crew Execution</h3><p>Staged execution flow with verification and fix loops.</p></article>
         <article class="card"><h3>MCP State Management</h3><p>Persistent lifecycle state, notepad, and project memory across sessions.</p></article>
       </div>
 
@@ -75,11 +120,17 @@
 
       <h2>Reference Guides</h2>
       <ul>
+        <li><a href="./reference/canonical-vocabulary.md">Canonical Vocabulary</a></li>
+        <li><a href="./reference/semantic-design-system.md">Semantic Design System</a></li>
+        <li><a href="./reference/roblox-workspace-standard.md">Roblox Workspace Standard</a></li>
+        <li><a href="./reference/robloxstudio-mcp-compatibility.md">robloxstudio-mcp Compatibility</a></li>
+        <li><a href="./reference/surface-map.md">Surface Map</a></li>
         <li><a href="./reference/rcs-config-schema-routing.md">.rcs-config.json model/env routing reference</a></li>
+        <li><a href="./archive/README.md">Archive Docs</a></li>
       </ul>
 
       <h2>Integration Guides</h2>
-      <p>OpenClaw / notification gateway setup and prompt-tuning guides by language:</p>
+      <p>Notification delivery and OpenClaw setup guides by language:</p>
       <p><a href="./integrations.html">Open dedicated Integrations page</a></p>
       <ul>
         <li><a href="./openclaw-integration.md">English</a></li>
@@ -101,7 +152,7 @@
       <h2>Architecture</h2>
       <pre><code>User
   -> Codex CLI
-     -> AGENTS.md (orchestration brain)
+     -> AGENTS.md (creator workflow brain)
      -> ~/.codex/prompts/*.md (installable active/internal agent prompt catalog)
      -> ~/.codex/skills/*/SKILL.md (skill catalog)
      -> ~/.codex/config.toml (features, notify, MCP)

package/docs/integrations.html

@@ -20,11 +20,12 @@
 
     <main class="container">
       <h1>Integrations</h1>
-      <p class="muted">OpenClaw and notification gateway setup + localized prompt-tuning guides.</p>
+      <p class="muted">Notification delivery and OpenClaw setup, plus localized operator guides.</p>
 
       <h2>Primary Guide (English)</h2>
       <ul>
-        <li><a href="./openclaw-integration.md">OpenClaw / Generic Notification Gateway Integration Guide</a></li>
+        <li><a href="./openclaw-integration.md">Notification Gateway and OpenClaw Integration Guide</a></li>
+        <li><a href="./reference/robloxstudio-mcp-compatibility.md">robloxstudio-mcp live Studio compatibility</a></li>
       </ul>
 
       <h2>Operator Troubleshooting</h2>
@@ -32,7 +33,7 @@
         <li><a href="./troubleshooting.md">Execution readiness after setup and doctor</a></li>
       </ul>
 
-      <h2>Localized Prompt-Tuning Guides</h2>
+      <h2>Localized Notification Guides</h2>
       <ul>
         <li><a href="./openclaw-integration.ko.md">한국어</a></li>
         <li><a href="./openclaw-integration.ja.md">日本語</a></li>

package/docs/issues/team-forge-followup-team.md

@@ -0,0 +1,38 @@
+# Issue Draft: Make `blueprint` first-class for `team` follow-up planning
+
+## Title
+[Feature] Make `blueprint` emit explicit `team` follow-up guidance (for example `--followup team`)
+
+## Problem
+RCS already has the ingredients for a strong high-control workflow: `blueprint` for scoped planning and `team` for durable multi-worker execution with its own verification lanes. What is still under-explained and under-productized is the handoff between planning and team execution.
+
+Today, experienced users can manually infer the pattern: run `blueprint`, then launch `team`, and let team own delivery plus verification unless a later single-owner follow-up is genuinely needed. The workflow's biggest advantage is not just parallelism. It is coordinated execution: teammates can surface blockers early, redistribute work, and stay inspectable through panes plus runtime state. That benefit should be reflected directly in planning output.
+
+## Proposed solution
+Teach `blueprint` to support an explicit team-oriented follow-up mode, such as `--followup team`, that produces:
+
+1. a normal implementation plan and acceptance criteria
+2. recommended worker lanes / role allocation
+3. suggested reasoning levels by lane
+4. explicit follow-up commands or launch hints for `rcs team` / `$team`
+5. verification expectations that fit a standalone `team` execution path, plus optional later Forge follow-up guidance only when needed
+
+This would make the intended workflow clearer:
+
+```text
+blueprint -> team
+```
+
+## Why this is good
+- Clarifies why `team` exists alongside `ultrawork`: team mode is about coordination and runtime control, not only fanout.
+- Reduces the gap between planning output and actual coordination flow.
+- Makes one of RCS's strongest workflows more discoverable for advanced users.
+- Improves execution quality on runtime-edge-case and workflow-edge-case work, where durable coordination matters more than raw task splitting.
+- Fits RCS's architecture well because the runtime already supports worker roles, mixed CLIs, runtime state, and inspectable team lifecycle commands.
+
+## Alternatives considered
+- Keep the pattern implicit in docs only. This helps discovery, but still leaves users to translate plans into worker lanes manually.
+- Fold everything into `autopilot`. Useful for default automation, but weaker for users who want direct control over planning, staffing, and verification.
+
+## Additional context
+Expected user outcome: a user runs `blueprint`, sees a plan that is already shaped for team execution, launches `team` with less guesswork, and only escalates to `forge` later if a persistent single-owner follow-up is still needed after team execution.

package/docs/openclaw-integration.md

@@ -1,6 +1,6 @@
-# OpenClaw / Generic Notification Gateway Integration Guide
+# Notification Gateway and OpenClaw Integration Guide
 
-This guide covers two supported setup paths:
+This guide covers the supported RCS notification delivery setup paths:
 
 1. **Explicit OpenClaw schema** (`notifications.openclaw`) — runtime-native shape
 2. **Generic aliases** (`custom_webhook_command`, `custom_cli_command`) — flexible setup for OpenClaw or other services

package/docs/prompt-guidance-contract.md

@@ -1,10 +1,10 @@
 # GPT-5.5 Prompt Guidance Contract
 
-Status: contributor-facing contract for RCS prompt and orchestration surfaces.
+Status: contributor-facing contract for RCS prompt and workflow surfaces.
 
 ## Purpose
 
-This document explains the active **behavioral prompt contract** for RCS after Issue [#2007](https://github.com/Yeachan-Heo/roblox-ai-os-creator-skills/issues/2007): align prompt and instruction surfaces with OpenAI's official [GPT-5.5 prompt guidance](https://developers.openai.com/api/docs/guides/prompt-guidance) while preserving RCS product contracts.
+This document explains the active **behavioral prompt contract** for RCS: align prompt and instruction surfaces with OpenAI's official [GPT-5.5 prompt guidance](https://developers.openai.com/api/docs/guides/prompt-guidance) while preserving RCS product contracts.
 
 Use it when you edit any of these surfaces:
 
@@ -20,7 +20,7 @@ The current prompt sources in this repository live in **`prompts/*.md`** and **`
 
 The GPT-5.5 contract is distributed across:
 
-- orchestration surfaces: `templates/AGENTS.md` and any tracked project-root `AGENTS.md`
+- root workflow surfaces: `templates/AGENTS.md` and any tracked project-root `AGENTS.md`
 - shared fragments: `docs/prompt-guidance-fragments/*`
 - canonical XML-tagged subagent role prompts: `prompts/*.md`
 - workflow skills: `skills/*/SKILL.md`
@@ -72,7 +72,7 @@ Representative locations:
 | Surface | Evidence |
 |---|---|
 | shared fragments | `docs/prompt-guidance-fragments/core-operating-principles.md` |
-| root orchestration | `templates/AGENTS.md` |
+| root workflow | `templates/AGENTS.md` |
 | core roles | `prompts/executor.md`, `prompts/planner.md`, `prompts/verifier.md` |
 | contract tests | `src/hooks/prompt-guidance-contract.ts` and `src/hooks/__tests__/prompt-guidance-*.test.ts` |
 
@@ -88,7 +88,7 @@ Representative locations:
 
 | Surface | Evidence |
 |---|---|
-| root orchestration | `templates/AGENTS.md` |
+| root workflow | `templates/AGENTS.md` |
 | executor/planner/verifier fragments | `docs/prompt-guidance-fragments/*-constraints.md` |
 | core prompts | `prompts/executor.md`, `prompts/planner.md`, `prompts/verifier.md` |
 
@@ -129,7 +129,7 @@ Implementation plans should stay traceable: requirements, named files/resources/
 
 ## Absolute-language rule
 
-Use `MUST`, `NEVER`, `ALWAYS`, `only`, and similar absolute wording for true invariants: safety/security boundaries, side-effect constraints, required output fields, workflow state transitions, team/ralph gates, and product contracts. For judgment calls such as whether to search again, ask for clarification, or keep iterating, prefer decision rules and stop conditions.
+Use `MUST`, `NEVER`, `ALWAYS`, `only`, and similar absolute wording for true invariants: safety/security boundaries, side-effect constraints, required output fields, workflow state transitions, team/forge compatibility gates, and product contracts. For judgment calls such as whether to search again, ask for clarification, or keep iterating, prefer decision rules and stop conditions.
 
 ## Active workflow terminal handoff contract
 
@@ -144,11 +144,11 @@ Contributor rules:
 
 This rule is specific to active workflow handoffs. Normal explanatory conversation outside an active workflow may still be conversational, but workflow-owned terminal replies must make the lifecycle state explicit.
 
-## Orchestration sharpness rules for root AGENTS surfaces
+## Workflow sharpness rules for root AGENTS surfaces
 
-When editing `templates/AGENTS.md`, any tracked root `AGENTS.md`, or other root orchestration guidance, keep the orchestration contract mode-driven and terse:
+When editing `templates/AGENTS.md`, any tracked root `AGENTS.md`, or other root workflow guidance, keep the contract mode-driven and terse:
 
-1. **Mode selection comes first.** Distinguish between `$deep-interview`, `$ralplan`, `$team`, and direct solo execution instead of blending them into one generic flow.
+1. **Mode selection comes first.** Distinguish between `$deep-interview`, `$blueprint`, `$team`, and direct solo execution instead of blending them into one generic flow.
 2. **Leader and worker responsibilities stay separate.** Leaders choose the mode, own verification, and integrate work; workers execute assigned slices and report blockers upward.
 3. **Stop/escalate rules are explicit.** The prompt should say when to stop, when to escalate to the user, and when workers must escalate back to the leader.
 4. **Output contract stays tight.** Default progress/final updates should be compact: current mode, action/result, and evidence or blocker/next step. Avoid repeating full-plan rationale unless the risk or decision changed.
@@ -227,7 +227,7 @@ npm test
 
 ## References
 
-- Implementation issue: [#2007](https://github.com/Yeachan-Heo/roblox-ai-os-creator-skills/issues/2007)
+- Implementation issue: internal prompt-guidance rollout issue `#2007`
 - Official source: [OpenAI GPT-5.5 prompt guidance](https://developers.openai.com/api/docs/guides/prompt-guidance)
-- Prior rollout history: [#608](https://github.com/Yeachan-Heo/roblox-ai-os-creator-skills/issues/608), [#611](https://github.com/Yeachan-Heo/roblox-ai-os-creator-skills/pull/611), [#612](https://github.com/Yeachan-Heo/roblox-ai-os-creator-skills/pull/612)
+- Prior rollout history: internal rollout references `#608`, `#611`, `#612`
 - Guidance schema: `docs/guidance-schema.md`

package/docs/prs/{dev-deprecate-team-ralph.md → dev-deprecate-team-forge.md}

@@ -1,27 +1,27 @@
 > Archive context: retained release and migration collateral from the pre-v0.1.0 fork-to-RCS transition. Links are normalized to the canonical JustineDevs repository, but historical chronology and contributor references may still describe pre-fork development.
 
-# PR Draft: Deprecate `rcs team ralph` and keep team standalone
+# PR Draft: Deprecate `rcs team forge` and keep team standalone
 
 ## Target branch
 `dev`
 
 ## Title
-Deprecate `rcs team ralph` and remove linked team↔Ralph lifecycle machinery
+Deprecate `rcs team forge` and remove linked team↔Forge lifecycle machinery
 
 ## Summary
-This PR removes the built-in linked `rcs team ralph` workflow and restores a clean separation between `team` and `ralph`.
+This PR removes the built-in linked `rcs team forge` workflow and restores a clean separation between `team` and `forge`.
 
 After this change:
 - `rcs team ...` / `$team ...` is the only supported team launch path
-- `rcs ralph ...` / `$ralph ...` remains available as a separate, explicit follow-up
-- team no longer creates, syncs, or depends on linked Ralph state
-- legacy `rcs team ralph ...` usage now fails with a clear deprecation error instead of being tolerated silently
+- `rcs forge ...` / `$forge ...` remains available as a separate, explicit follow-up
+- team no longer creates, syncs, or depends on linked Forge state
+- legacy `rcs team forge ...` usage now fails with a clear deprecation error instead of being tolerated silently
 
-This matches the intended product model: team can own coordinated execution and verification itself, while Ralph remains an independent persistence loop that a leader or separate worker may choose to run later.
+This matches the intended product model: team can own coordinated execution and verification itself, while Forge remains an independent persistence loop that a leader or separate worker may choose to run later.
 
 ## Why
-The old team↔Ralph linkage had become bloated orchestration glue:
-- bridge code between team and Ralph mode state
+The old team↔Forge linkage had become bloated orchestration glue:
+- bridge code between team and Forge mode state
 - linked lifecycle/profile branching
 - notify-hook terminal sync behavior
 - cleanup/shutdown special-casing
@@ -31,23 +31,23 @@ That coupling made the runtime harder to reason about without providing enough v
 
 ## What changed
 ### Removed
-- linked team↔Ralph runtime bridge
+- linked team↔Forge runtime bridge
 - linked notify-hook terminal sync
 - linked cleanup/shutdown policy behavior
-- `linked_ralph` lifecycle profile handling
-- advertised/generated `rcs team ralph ...` launch hints
-- linked-Ralph-specific tests and compatibility paths inside team runtime
+- `linked_forge` lifecycle profile handling
+- advertised/generated `rcs team forge ...` launch hints
+- linked-Forge-specific tests and compatibility paths inside team runtime
 
 ### Updated
 - team help/usage text now documents only `rcs team [N:agent-type] "<task>"`
-- planning, ralplan, team, and deep-interview guidance now describe a **team verification path** rather than a built-in `team -> ralph` lifecycle
+- planning, blueprint, team, and deep-interview guidance now describe a **team verification path** rather than a built-in `team -> forge` lifecycle
 - follow-up planner and pipeline launch hints now generate plain `rcs team ...`
 - shutdown/resume/state flows now operate on standalone team semantics only
 
 ### Behavior change
-- `rcs team ralph ...` is now rejected with an explicit deprecation error:
+- `rcs team forge ...` is now rejected with an explicit deprecation error:
   - use `rcs team ...` for coordinated team execution
-  - use `rcs ralph ...` separately if a later persistent follow-up loop is still needed
+  - use `rcs forge ...` separately if a later persistent follow-up loop is still needed
 
 ## Notable implementation areas
 - `src/cli/team.ts`
@@ -62,25 +62,25 @@ That coupling made the runtime harder to reason about without providing enough v
 - `src/pipeline/stages/team-exec.ts`
 
 ## Deleted surfaces
-- `src/team/linked-ralph-bridge.ts`
+- `src/team/linked-forge-bridge.ts`
 - `src/scripts/notify-hook/linked-sync.ts`
-- `src/cli/__tests__/team-linked-ralph.test.ts`
-- `src/team/__tests__/linked-ralph-bridge.test.ts`
+- `src/cli/__tests__/team-linked-forge.test.ts`
+- `src/team/__tests__/linked-forge-bridge.test.ts`
 - `src/hooks/__tests__/notify-hook-linked-sync.test.ts`
 
 ## Impact
 ### Before
-- `rcs team ralph ...` had special runtime behavior
-- team state could carry linked Ralph metadata
-- notify-hook and shutdown logic had linked team↔Ralph branches
+- `rcs team forge ...` had special runtime behavior
+- team state could carry linked Forge metadata
+- notify-hook and shutdown logic had linked team↔Forge branches
 - docs/planning artifacts promoted a built-in linked verification path
 
 ### After
 - `rcs team ...` runs coordinated team execution only
 - team owns its own verification lanes and shutdown evidence
-- `rcs ralph ...` is separate and explicit
-- a leader or separate worker may still choose to run Ralph later
-- there is no built-in linked team+Ralph lifecycle anymore
+- `rcs forge ...` is separate and explicit
+- a leader or separate worker may still choose to run Forge later
+- there is no built-in linked team+Forge lifecycle anymore
 
 ## Validation
 - [x] `npm run build`
@@ -95,6 +95,6 @@ Result:
 - `428 pass, 0 fail`
 
 ## Risks / notes
-- This is an intentional CLI behavior break for users still invoking `rcs team ralph ...`
+- This is an intentional CLI behavior break for users still invoking `rcs team forge ...`
 - The break is now explicit and easier to understand than the previous silent compatibility path
-- Separate Ralph execution remains supported, but it must be initiated intentionally rather than being baked into team runtime semantics
+- Separate Forge execution remains supported, but it must be initiated intentionally rather than being baked into team runtime semantics

package/docs/prs/{dev-fix-ralph-live-pane-invariant.md → dev-fix-forge-live-pane-invariant.md}

@@ -1,34 +1,34 @@
 > Archive context: retained release and migration collateral from the pre-v0.1.0 fork-to-RCS transition. Links are normalized to the canonical JustineDevs repository, but historical chronology and contributor references may still describe pre-fork development.
 
-# PR Draft: Preserve verified Ralph pane anchors and avoid tmux-hook target drift
+# PR Draft: Preserve verified Forge pane anchors and avoid tmux-hook target drift
 
 ## Target branch
 `dev`
 
 ## Summary
-This follow-up fixes pane rebinding drift in the managed tmux recovery paths that showed up during review of the Ralph resume / continue work.
+This follow-up fixes pane rebinding drift in the managed tmux recovery paths that showed up during review of the Forge resume / continue work.
 
-The main issue was stored-pane drift. Once a Ralph pane anchor had already been verified as part of the correct managed session, recovery could still rescan the whole tmux session and rebind to whichever Codex pane was currently focused, or fall back to a shell-degraded pane that only historically started as Codex. In multi-pane Codex sessions that could silently move future watcher or auto-nudge injections onto the wrong lane.
+The main issue was stored-pane drift. Once a Forge pane anchor had already been verified as part of the correct managed session, recovery could still rescan the whole tmux session and rebind to whichever Codex pane was currently focused, or fall back to a shell-degraded pane that only historically started as Codex. In multi-pane Codex sessions that could silently move future watcher or auto-nudge injections onto the wrong lane.
 
 On current `dev`, the pre-guard tmux-hook target drift path is already absent in production code. This branch keeps that invariant covered with a focused regression so the repo-scoped session target does not get rewritten on skipped turns.
 
 ## Changes
 - split managed-pane heuristics so `TMUX_PANE` detection can stay permissive while stored-anchor retention stays strict
 - keep the verified anchor pane in `resolveManagedPaneFromAnchor()` only when it still looks like a live Codex-managed pane instead of a shell that merely started as Codex, while still retaining a verified anchor on transient command-state lookup failure
-- teach the Ralph continue watcher to re-resolve stored pane anchors against the current managed session before sending continue nudges
+- teach the Forge continue watcher to re-resolve stored pane anchors against the current managed session before sending continue nudges
 - only rescan the tmux session when the anchor is gone or no longer looks agent-owned, and fail closed when no live managed sibling exists
 - add regressions for the direct managed-pane helper, watcher rebinding behavior, auto-nudge anchor retention / node-shell upgrade paths, and pre-guard config-drift handling
 
 ## Why this is good
-- prevents Ralph continue / resume state from jumping between Codex panes just because focus changed
+- prevents Forge continue / resume state from jumping between Codex panes just because focus changed
 - keeps watcher and auto-nudge behavior aligned with the stored managed anchor contract
 - keeps the current `dev` pre-guard skip invariant locked by test so repo-scoped session targets do not drift back to pane ids
 - makes watcher recovery follow the same live-anchor contract as notify-hook / auto-nudge
 
 ## Validation
-- [x] `npx biome lint src/scripts/notify-hook/managed-tmux.ts src/scripts/notify-fallback-watcher.ts src/scripts/notify-hook/auto-nudge.ts src/hooks/__tests__/notify-hook-managed-tmux.test.ts src/hooks/__tests__/notify-hook-tmux-heal.test.ts src/hooks/__tests__/notify-fallback-watcher.test.ts src/hooks/__tests__/notify-hook-auto-nudge.test.ts docs/prs/dev-fix-ralph-live-pane-invariant.md`
+- [x] `npx biome lint src/scripts/notify-hook/managed-tmux.ts src/scripts/notify-fallback-watcher.ts src/scripts/notify-hook/auto-nudge.ts src/hooks/__tests__/notify-hook-managed-tmux.test.ts src/hooks/__tests__/notify-hook-tmux-heal.test.ts src/hooks/__tests__/notify-fallback-watcher.test.ts src/hooks/__tests__/notify-hook-auto-nudge.test.ts docs/prs/dev-fix-forge-live-pane-invariant.md`
 - [x] `npm run build`
 - [x] `node --test dist/hooks/__tests__/notify-fallback-watcher.test.js dist/hooks/__tests__/notify-hook-auto-nudge.test.js dist/hooks/__tests__/notify-hook-managed-tmux.test.js dist/hooks/__tests__/notify-hook-tmux-heal.test.js`
 
 ## Related
-- follow-up to the Ralph resume / managed tmux healing review pass
+- follow-up to the Forge resume / managed tmux healing review pass

package/docs/prs/{dev-team-ralph-workflow-positioning.md → dev-team-forge-workflow-positioning.md}

@@ -1,19 +1,19 @@
 > Archive context: retained release and migration collateral from the pre-v0.1.0 fork-to-RCS transition. Links are normalized to the canonical JustineDevs repository, but historical chronology and contributor references may still describe pre-fork development.
 
-# PR Draft: Document the `ralplan -> team -> ralph` workflow
+# PR Draft: Document the `blueprint -> team -> forge` workflow
 
 ## Target branch
 `dev`
 
 ## Summary
-This PR documents one of RCS's strongest high-control workflows: `ralplan -> team -> ralph`. The goal is to make the README explain not only that team mode exists, but why it matters even when `$ultrawork` already provides parallel execution.
+This PR documents one of RCS's strongest high-control workflows: `blueprint -> team -> forge`. The goal is to make the README explain not only that team mode exists, but why it matters even when `$ultrawork` already provides parallel execution.
 
-The key point is that team mode is not just fanout. It is coordinated, inspectable, runtime-aware execution. Workers can share blocker awareness, execution stays visible through tmux panes plus durable state, and the leader retains stronger control over recovery and lifecycle commands. Pairing that with `ralplan` up front and `ralph` at the back creates a workflow that is both fast and operationally disciplined.
+The key point is that team mode is not just fanout. It is coordinated, inspectable, runtime-aware execution. Workers can share blocker awareness, execution stays visible through tmux panes plus durable state, and the leader retains stronger control over recovery and lifecycle commands. Pairing that with `blueprint` up front and `forge` at the back creates a workflow that is both fast and operationally disciplined.
 
 ## Changes
 - clarify the positioning difference between `$team` and `$ultrawork`
-- add README guidance for the recommended high-control workflow: `ralplan -> team -> ralph`
-- add an issue draft proposing stronger `ralplan` support for team follow-up planning, such as `--followup team`
+- add README guidance for the recommended high-control workflow: `blueprint -> team -> forge`
+- add an issue draft proposing stronger `blueprint` support for team follow-up planning, such as `--followup team`
 
 ## Why this is good
 - Explains a real product strength more clearly to contributors and users.
@@ -22,7 +22,7 @@ The key point is that team mode is not just fanout. It is coordinated, inspectab
 - Makes `autopilot` easier to explain too, because it can be described as an automatic chaining layer over the same underlying workflow.
 
 ## Design direction
-The docs position `ralplan` as the place where team follow-up should become more explicit. In future work, `ralplan` can emit lane recommendations, role placement hints, and launch guidance for a direct `team` handoff, while `ralph` remains the persistence and verification layer.
+The docs position `blueprint` as the place where team follow-up should become more explicit. In future work, `blueprint` can emit lane recommendations, role placement hints, and launch guidance for a direct `team` handoff, while `forge` remains the persistence and verification layer.
 
 ## Expected outcomes
 - Better onboarding for users evaluating RCS's orchestration model
@@ -35,4 +35,4 @@ The docs position `ralplan` as the place where team follow-up should become more
 - [ ] `npm test`
 
 ## Related
-- Proposed issue: `docs/issues/team-ralph-followup-team.md`
+- Proposed issue: `docs/issues/team-forge-followup-team.md`

package/docs/qa/forge-persistence-gate.md

@@ -0,0 +1,20 @@
+# Forge Persistence Gate
+
+Release gate checklist for the lower-level persistent completion runtime.
+
+| ID | Scenario | Required evidence | Status |
+|---|---|---|---|
+| V1 | Session-scoped state is preferred over root fallback | state-path + session runtime tests | [x] |
+| V2 | Cross-session safety is preserved | session/runtime compatibility tests | [x] |
+| V3 | Legacy PRD/progress migration is one-way and deterministic | forge persistence tests | [x] |
+| V4 | Legacy phase normalization is enforced | state-server phase tests | [x] |
+| V5 | Terminal completion is persisted correctly | lifecycle/runtime tests | [x] |
+| V6 | Linked cleanup behavior is preserved | cancel/runtime tests | [x] |
+| V7 | Cancellation produces terminal non-active state | cancel contract tests | [x] |
+| V8 | Notify/runtime readers honor authoritative scope | HUD / notify / trace tests | [x] |
+| V9 | Prompt-side activation does not bypass explicit PRD startup rules | forge PRD tests | [x] |
+| V10 | CI blocks release when this matrix is not covered | forge persistence gate test + CI job | [x] |
+
+Compatibility window note:
+- `RCS_FORGE_PERSISTENCE_PORT=1` is the current release-port marker.
+- Older migration notes may still mention pre-Forge persistence markers; those are historical only and no longer canonical.

package/docs/qa/rust-runtime-thin-adapter-gate.md

@@ -1,40 +1,31 @@
-HaD0Yun>HaD0Yun HaD0YunAHaD0YunrHaD0YuncHaD0YunhHaD0YuniHaD0YunvHaD0YuneHaD0Yun HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YuneHaD0YunxHaD0YuntHaD0Yun:HaD0Yun HaD0YunrHaD0YuneHaD0YuntHaD0YunaHaD0YuniHaD0YunnHaD0YuneHaD0YundHaD0Yun HaD0YunrHaD0YuneHaD0YunlHaD0YuneHaD0YunaHaD0YunsHaD0YuneHaD0Yun HaD0YunaHaD0YunnHaD0YundHaD0Yun HaD0YunmHaD0YuniHaD0YungHaD0YunrHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YuncHaD0YunoHaD0YunlHaD0YunlHaD0YunaHaD0YuntHaD0YuneHaD0YunrHaD0YunaHaD0YunlHaD0Yun HaD0YunfHaD0YunrHaD0YunoHaD0YunmHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0Yun-HaD0YunvHaD0Yun0HaD0Yun.HaD0Yun1HaD0Yun.HaD0Yun0HaD0Yun HaD0YunfHaD0YunoHaD0YunrHaD0YunkHaD0Yun-HaD0YuntHaD0YunoHaD0Yun-HaD0YunRHaD0YunCHaD0YunSHaD0Yun HaD0YuntHaD0YunrHaD0YunaHaD0YunnHaD0YunsHaD0YuniHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun.HaD0Yun HaD0YunLHaD0YuniHaD0YunnHaD0YunkHaD0YunsHaD0Yun HaD0YunaHaD0YunrHaD0YuneHaD0Yun HaD0YunnHaD0YunoHaD0YunrHaD0YunmHaD0YunaHaD0YunlHaD0YuniHaD0YunzHaD0YuneHaD0YundHaD0Yun HaD0YuntHaD0YunoHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YuncHaD0YunaHaD0YunnHaD0YunoHaD0YunnHaD0YuniHaD0YuncHaD0YunaHaD0YunlHaD0Yun HaD0YunJHaD0YunuHaD0YunsHaD0YuntHaD0YuniHaD0YunnHaD0YuneHaD0YunDHaD0YuneHaD0YunvHaD0YunsHaD0Yun HaD0YunrHaD0YuneHaD0YunpHaD0YunoHaD0YunsHaD0YuniHaD0YuntHaD0YunoHaD0YunrHaD0YunyHaD0Yun,HaD0Yun HaD0YunbHaD0YunuHaD0YuntHaD0Yun HaD0YunhHaD0YuniHaD0YunsHaD0YuntHaD0YunoHaD0YunrHaD0YuniHaD0YuncHaD0YunaHaD0YunlHaD0Yun HaD0YuncHaD0YunhHaD0YunrHaD0YunoHaD0YunnHaD0YunoHaD0YunlHaD0YunoHaD0YungHaD0YunyHaD0Yun HaD0YunaHaD0YunnHaD0YundHaD0Yun HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YuniHaD0YunbHaD0YunuHaD0YuntHaD0YunoHaD0YunrHaD0Yun HaD0YunrHaD0YuneHaD0YunfHaD0YuneHaD0YunrHaD0YuneHaD0YunnHaD0YuncHaD0YuneHaD0YunsHaD0Yun HaD0YunmHaD0YunaHaD0YunyHaD0Yun HaD0YunsHaD0YuntHaD0YuniHaD0YunlHaD0YunlHaD0Yun HaD0YundHaD0YuneHaD0YunsHaD0YuncHaD0YunrHaD0YuniHaD0YunbHaD0YuneHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0Yun-HaD0YunfHaD0YunoHaD0YunrHaD0YunkHaD0Yun HaD0YundHaD0YuneHaD0YunvHaD0YuneHaD0YunlHaD0YunoHaD0YunpHaD0YunmHaD0YuneHaD0YunnHaD0YuntHaD0Yun.HaD0Yun
-HaD0Yun
-HaD0Yun#HaD0Yun HaD0YunRHaD0YunuHaD0YunsHaD0YuntHaD0Yun HaD0YunRHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun HaD0YunTHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunAHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun HaD0YunRHaD0YuneHaD0YunlHaD0YuneHaD0YunaHaD0YunsHaD0YuneHaD0Yun HaD0YunGHaD0YunaHaD0YuntHaD0YuneHaD0Yun
-HaD0Yun
-HaD0YunTHaD0YunhHaD0YuniHaD0YunsHaD0Yun HaD0YuncHaD0YunhHaD0YuneHaD0YuncHaD0YunkHaD0YunlHaD0YuniHaD0YunsHaD0YuntHaD0Yun HaD0YuniHaD0YunsHaD0Yun HaD0YunaHaD0Yun HaD0YunhHaD0YunaHaD0YunrHaD0YundHaD0Yun HaD0YungHaD0YunaHaD0YuntHaD0YuneHaD0Yun HaD0YunfHaD0YunoHaD0YunrHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunRHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YuncHaD0YunoHaD0YunrHaD0YuneHaD0Yun HaD0Yun+HaD0Yun HaD0YuntHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun HaD0YuncHaD0YunuHaD0YuntHaD0YunoHaD0YunvHaD0YuneHaD0YunrHaD0Yun.HaD0Yun
-HaD0YunCHaD0YunIHaD0Yun/HaD0YunrHaD0YuneHaD0YunlHaD0YuneHaD0YunaHaD0YunsHaD0YuneHaD0Yun HaD0YunvHaD0YunaHaD0YunlHaD0YuniHaD0YundHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YunMHaD0YunUHaD0YunSHaD0YunTHaD0Yun HaD0YunfHaD0YunaHaD0YuniHaD0YunlHaD0Yun HaD0YunwHaD0YunhHaD0YuneHaD0YunnHaD0Yun HaD0YunaHaD0YunnHaD0YunyHaD0Yun HaD0YunrHaD0YuneHaD0YunqHaD0YunuHaD0YuniHaD0YunrHaD0YuneHaD0YundHaD0Yun HaD0YunsHaD0YuncHaD0YuneHaD0YunnHaD0YunaHaD0YunrHaD0YuniHaD0YunoHaD0Yun HaD0YunbHaD0YuneHaD0YunlHaD0YunoHaD0YunwHaD0Yun HaD0YuniHaD0YunsHaD0Yun HaD0YunmHaD0YuniHaD0YunsHaD0YunsHaD0YuniHaD0YunnHaD0YungHaD0Yun HaD0YunoHaD0YunrHaD0Yun
-HaD0YunfHaD0YunaHaD0YuniHaD0YunlHaD0YuniHaD0YunnHaD0YungHaD0Yun.HaD0Yun
-HaD0Yun
-HaD0Yun#HaD0Yun#HaD0Yun HaD0YunVHaD0YuneHaD0YunrHaD0YuniHaD0YunfHaD0YuniHaD0YuncHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YunmHaD0YunaHaD0YuntHaD0YunrHaD0YuniHaD0YunxHaD0Yun HaD0YungHaD0YunaHaD0YuntHaD0YuneHaD0Yun
-HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunIHaD0YunDHaD0Yun HaD0Yun|HaD0Yun HaD0YunSHaD0YuncHaD0YuneHaD0YunnHaD0YunaHaD0YunrHaD0YuniHaD0YunoHaD0Yun HaD0Yun|HaD0Yun HaD0YunRHaD0YuneHaD0YunqHaD0YunuHaD0YuniHaD0YunrHaD0YuneHaD0YundHaD0Yun HaD0YuneHaD0YunvHaD0YuniHaD0YundHaD0YuneHaD0YunnHaD0YuncHaD0YuneHaD0Yun HaD0Yun|HaD0Yun HaD0YunSHaD0YuntHaD0YunaHaD0YuntHaD0YunuHaD0YunsHaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunGHaD0Yun1HaD0Yun HaD0Yun|HaD0Yun HaD0YunTHaD0YuneHaD0YunaHaD0YunmHaD0Yun HaD0YunsHaD0YuntHaD0YunaHaD0YuntHaD0YunuHaD0YunsHaD0Yun HaD0YunrHaD0YuneHaD0YunaHaD0YundHaD0YunsHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunmHaD0YunaHaD0YunnHaD0YuniHaD0YunfHaD0YuneHaD0YunsHaD0YuntHaD0Yun-HaD0YunaHaD0YunuHaD0YuntHaD0YunhHaD0YunoHaD0YunrHaD0YuneHaD0YundHaD0Yun HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0YuniHaD0YunbHaD0YuniHaD0YunlHaD0YuniHaD0YuntHaD0YunyHaD0Yun HaD0YunvHaD0YuniHaD0YuneHaD0YunwHaD0Yun HaD0Yun|HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun HaD0Yun|HaD0Yun HaD0Yun[HaD0YunxHaD0Yun]HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunGHaD0Yun2HaD0Yun HaD0Yun|HaD0Yun HaD0YunDHaD0YunoHaD0YuncHaD0YuntHaD0YunoHaD0YunrHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0YunsHaD0YuneHaD0YunrHaD0YunvHaD0YuneHaD0YunsHaD0Yun HaD0YunmHaD0YunaHaD0YunnHaD0YuniHaD0YunfHaD0YuneHaD0YunsHaD0YuntHaD0Yun-HaD0YunfHaD0YuniHaD0YunrHaD0YunsHaD0YuntHaD0Yun HaD0YuntHaD0YunmHaD0YunuHaD0YunxHaD0Yun/HaD0YunsHaD0YuneHaD0YunsHaD0YunsHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0YuncHaD0YuneHaD0YundHaD0YuneHaD0YunnHaD0YuncHaD0YuneHaD0Yun HaD0Yun|HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun HaD0Yun|HaD0Yun HaD0Yun[HaD0YunxHaD0Yun]HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunGHaD0Yun3HaD0Yun HaD0Yun|HaD0Yun HaD0YunHHaD0YunUHaD0YunDHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0YunsHaD0YuneHaD0YunrHaD0YunvHaD0YuneHaD0YunsHaD0Yun HaD0YunsHaD0YuneHaD0YunsHaD0YunsHaD0YuniHaD0YunoHaD0YunnHaD0Yun-HaD0YunsHaD0YuncHaD0YunoHaD0YunpHaD0YuneHaD0YundHaD0Yun HaD0YunsHaD0YuntHaD0YunaHaD0YuntHaD0YuneHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0YuncHaD0YuneHaD0YundHaD0YuneHaD0YunnHaD0YuncHaD0YuneHaD0Yun HaD0YunoHaD0YunvHaD0YuneHaD0YunrHaD0Yun HaD0YunrHaD0YunoHaD0YunoHaD0YuntHaD0Yun HaD0YunfHaD0YunaHaD0YunlHaD0YunlHaD0YunbHaD0YunaHaD0YuncHaD0YunkHaD0Yun HaD0Yun|HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun HaD0Yun|HaD0Yun HaD0Yun[HaD0YunxHaD0Yun]HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunGHaD0Yun4HaD0Yun HaD0Yun|HaD0Yun HaD0YunTHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0Yun HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun HaD0YunsHaD0YuntHaD0YunaHaD0YunyHaD0Yun HaD0YunaHaD0YunlHaD0YuniHaD0YungHaD0YunnHaD0YuneHaD0YundHaD0Yun HaD0YunwHaD0YuniHaD0YuntHaD0YunhHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunrHaD0YuneHaD0YunaHaD0YundHaD0YuneHaD0YunrHaD0Yun HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0YuniHaD0YunbHaD0YuniHaD0YunlHaD0YuniHaD0YuntHaD0YunyHaD0Yun HaD0YunlHaD0YunaHaD0YunnHaD0YuneHaD0Yun HaD0Yun|HaD0Yun HaD0Yun`HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun/HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0YunsHaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuntHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun-HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0Yun.HaD0YunmHaD0YundHaD0Yun`HaD0Yun HaD0Yun+HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YunvHaD0YuneHaD0YunrHaD0YuniHaD0YunfHaD0YuniHaD0YuncHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuntHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun-HaD0YungHaD0YunaHaD0YuntHaD0YuneHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun HaD0Yun|HaD0Yun HaD0Yun[HaD0YunxHaD0Yun]HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunGHaD0Yun5HaD0Yun HaD0Yun|HaD0Yun HaD0YunWHaD0YunaHaD0YuntHaD0YuncHaD0YunhHaD0YuneHaD0YunrHaD0Yun HaD0YunsHaD0YuneHaD0YunnHaD0YundHaD0Yun-HaD0YunkHaD0YuneHaD0YunyHaD0YunsHaD0Yun HaD0YunpHaD0YunaHaD0YunrHaD0YuniHaD0YuntHaD0YunyHaD0Yun HaD0YunsHaD0YuntHaD0YunaHaD0YunyHaD0YunsHaD0Yun HaD0YuncHaD0YunoHaD0YunvHaD0YuneHaD0YunrHaD0YuneHaD0YundHaD0Yun HaD0YunbHaD0YunyHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunSHaD0YuntHaD0YuneHaD0YunpHaD0Yun HaD0Yun3HaD0Yun HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YunnHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YunsHaD0YunuHaD0YuniHaD0YuntHaD0YuneHaD0YunsHaD0Yun HaD0Yun|HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YunhHaD0YunoHaD0YunoHaD0YunkHaD0YunsHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunnHaD0YunoHaD0YuntHaD0YuniHaD0YunfHaD0YunyHaD0Yun-HaD0YunhHaD0YunoHaD0YunoHaD0YunkHaD0Yun-HaD0YuntHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YundHaD0YuniHaD0YunsHaD0YunpHaD0YunaHaD0YuntHaD0YuncHaD0YunhHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun,HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YunhHaD0YunoHaD0YunoHaD0YunkHaD0YunsHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YunnHaD0YunoHaD0YuntHaD0YuniHaD0YunfHaD0YunyHaD0Yun-HaD0YunhHaD0YunoHaD0YunoHaD0YunkHaD0Yun-HaD0YuntHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunlHaD0YuneHaD0YunaHaD0YundHaD0YuneHaD0YunrHaD0Yun-HaD0YunnHaD0YunuHaD0YundHaD0YungHaD0YuneHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun,HaD0Yun HaD0Yun`HaD0YunsHaD0YunrHaD0YuncHaD0Yun/HaD0YunnHaD0YunoHaD0YuntHaD0YuniHaD0YunfHaD0YuniHaD0YuncHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0YunsHaD0Yun/HaD0Yun_HaD0Yun_HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0YunsHaD0Yun_HaD0Yun_HaD0Yun/HaD0YuntHaD0YunmHaD0YunuHaD0YunxHaD0Yun-HaD0YundHaD0YuneHaD0YuntHaD0YuneHaD0YuncHaD0YuntHaD0YunoHaD0YunrHaD0Yun.HaD0YuntHaD0YuneHaD0YunsHaD0YuntHaD0Yun.HaD0YuntHaD0YunsHaD0Yun`HaD0Yun HaD0Yun|HaD0Yun HaD0Yun[HaD0YunxHaD0Yun]HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun
-HaD0Yun#HaD0Yun#HaD0Yun HaD0YunPHaD0YunrHaD0YuneHaD0Yun-HaD0YunmHaD0YunoHaD0YunrHaD0YuntHaD0YuneHaD0YunmHaD0Yun HaD0YunsHaD0YuncHaD0YuneHaD0YunnHaD0YunaHaD0YunrHaD0YuniHaD0YunoHaD0Yun HaD0YunmHaD0YunaHaD0YunpHaD0YunpHaD0YuniHaD0YunnHaD0YungHaD0Yun
-HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunPHaD0YunrHaD0YuneHaD0Yun-HaD0YunmHaD0YunoHaD0YunrHaD0YuntHaD0YuneHaD0YunmHaD0Yun HaD0YunsHaD0YuncHaD0YuneHaD0YunnHaD0YunaHaD0YunrHaD0YuniHaD0YunoHaD0Yun HaD0Yun|HaD0Yun HaD0YunGHaD0YunaHaD0YuntHaD0YuneHaD0Yun(HaD0YunsHaD0Yun)HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun-HaD0Yun-HaD0Yun-HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunSHaD0YuneHaD0YunmHaD0YunaHaD0YunnHaD0YuntHaD0YuniHaD0YuncHaD0Yun HaD0YunlHaD0YuneHaD0YunaHaD0YunkHaD0YunaHaD0YungHaD0YuneHaD0Yun HaD0YunsHaD0YunuHaD0YunrHaD0YunvHaD0YuniHaD0YunvHaD0YuneHaD0YunsHaD0Yun HaD0YuniHaD0YunnHaD0YuntHaD0YunoHaD0Yun HaD0YunlHaD0YuneHaD0YungHaD0YunaHaD0YuncHaD0YunyHaD0Yun HaD0YunrHaD0YuneHaD0YunaHaD0YundHaD0YuneHaD0YunrHaD0YunsHaD0Yun HaD0Yun|HaD0Yun HaD0YunGHaD0Yun1HaD0Yun,HaD0Yun HaD0YunGHaD0Yun2HaD0Yun,HaD0Yun HaD0YunGHaD0Yun3HaD0Yun,HaD0Yun HaD0YunGHaD0Yun4HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunRHaD0YuneHaD0YunaHaD0YundHaD0YuneHaD0YunrHaD0Yun HaD0YunpHaD0YunrHaD0YuneHaD0YuncHaD0YuneHaD0YundHaD0YuneHaD0YunnHaD0YuncHaD0YuneHaD0Yun HaD0YundHaD0YunrHaD0YuniHaD0YunfHaD0YuntHaD0YunsHaD0Yun HaD0YunbHaD0YuneHaD0YuntHaD0YunwHaD0YuneHaD0YuneHaD0YunnHaD0Yun HaD0YuncHaD0YunoHaD0YunnHaD0YunfHaD0YuniHaD0YungHaD0Yun/HaD0YunmHaD0YunaHaD0YunnHaD0YuniHaD0YunfHaD0YuneHaD0YunsHaD0YuntHaD0Yun HaD0YunoHaD0YunrHaD0Yun HaD0YunsHaD0YuneHaD0YunsHaD0YunsHaD0YuniHaD0YunoHaD0YunnHaD0Yun/HaD0YunrHaD0YunoHaD0YunoHaD0YuntHaD0Yun HaD0YunsHaD0YuncHaD0YunoHaD0YunpHaD0YuneHaD0YunsHaD0Yun HaD0Yun|HaD0Yun HaD0YunGHaD0Yun1HaD0Yun,HaD0Yun HaD0YunGHaD0Yun2HaD0Yun,HaD0Yun HaD0YunGHaD0Yun3HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunWHaD0YunaHaD0YuntHaD0YuncHaD0YunhHaD0YuneHaD0YunrHaD0Yun HaD0YunsHaD0YuneHaD0YunnHaD0YundHaD0Yun-HaD0YunkHaD0YuneHaD0YunyHaD0YunsHaD0Yun HaD0YunpHaD0YunaHaD0YunrHaD0YuniHaD0YuntHaD0YunyHaD0Yun HaD0YunbHaD0YunrHaD0YuneHaD0YunaHaD0YunkHaD0YunsHaD0Yun HaD0Yun|HaD0Yun HaD0YunGHaD0Yun5HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun|HaD0Yun HaD0YunMHaD0YunuHaD0YunxHaD0Yun HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0Yun HaD0YunsHaD0YuntHaD0YunaHaD0YunyHaD0YunsHaD0Yun HaD0YuntHaD0YunmHaD0YunuHaD0YunxHaD0Yun-HaD0YunsHaD0YunhHaD0YunaHaD0YunpHaD0YuneHaD0YundHaD0Yun HaD0YuniHaD0YunnHaD0YunsHaD0YuntHaD0YuneHaD0YunaHaD0YundHaD0Yun HaD0YunoHaD0YunfHaD0Yun HaD0YunRHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YuncHaD0YunaHaD0YunnHaD0YunoHaD0YunnHaD0YuniHaD0YuncHaD0YunaHaD0YunlHaD0Yun HaD0Yun|HaD0Yun HaD0YunGHaD0Yun4HaD0Yun HaD0Yun|HaD0Yun
-HaD0Yun
-HaD0Yun#HaD0Yun#HaD0Yun HaD0YunRHaD0YuneHaD0YunqHaD0YunuHaD0YuniHaD0YunrHaD0YuneHaD0YundHaD0Yun HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun
-HaD0Yun
-HaD0Yun-HaD0Yun HaD0Yun`HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun/HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0YunsHaD0Yun/HaD0YunrHaD0YunuHaD0YunsHaD0YuntHaD0Yun-HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuntHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun-HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0Yun.HaD0YunmHaD0YundHaD0Yun`HaD0Yun
-HaD0Yun-HaD0Yun HaD0Yun`HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun/HaD0YuniHaD0YunnHaD0YuntHaD0YuneHaD0YunrHaD0YunoHaD0YunpHaD0Yun-HaD0YuntHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunmHaD0YunuHaD0YuntHaD0YunaHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun-HaD0YuncHaD0YunoHaD0YunnHaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YuntHaD0Yun.HaD0YunmHaD0YundHaD0Yun`HaD0Yun
-HaD0Yun-HaD0Yun HaD0Yun`HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun/HaD0YunqHaD0YunaHaD0Yun/HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuntHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunsHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunaHaD0YunuHaD0YundHaD0YuniHaD0YuntHaD0Yun-HaD0Yun2HaD0Yun0HaD0Yun2HaD0Yun6HaD0Yun-HaD0Yun0HaD0Yun4HaD0Yun-HaD0Yun0HaD0Yun1HaD0Yun.HaD0YunmHaD0YundHaD0Yun`HaD0Yun HaD0Yun(HaD0YunnHaD0YunoHaD0YunnHaD0Yun-HaD0YungHaD0YunaHaD0YuntHaD0YuniHaD0YunnHaD0YungHaD0Yun HaD0YunfHaD0YunoHaD0YunlHaD0YunlHaD0YunoHaD0YunwHaD0Yun-HaD0YunuHaD0YunpHaD0Yun HaD0YunsHaD0YuneHaD0YunaHaD0YunmHaD0Yun HaD0YunsHaD0YunnHaD0YunaHaD0YunpHaD0YunsHaD0YunhHaD0YunoHaD0YuntHaD0Yun)HaD0Yun
-HaD0Yun
-HaD0Yun#HaD0Yun#HaD0Yun HaD0YunNHaD0YunoHaD0YunnHaD0Yun-HaD0YungHaD0YunaHaD0YuntHaD0YuniHaD0YunnHaD0YungHaD0Yun HaD0YunfHaD0YunoHaD0YunlHaD0YunlHaD0YunoHaD0YunwHaD0Yun-HaD0YunuHaD0YunpHaD0Yun HaD0YunaHaD0YunuHaD0YundHaD0YuniHaD0YuntHaD0Yun
-HaD0Yun
-HaD0YunTHaD0YunhHaD0YuneHaD0Yun HaD0YuncHaD0YunuHaD0YunrHaD0YunrHaD0YuneHaD0YunnHaD0YuntHaD0Yun HaD0YuntHaD0YunhHaD0YuniHaD0YunnHaD0Yun-HaD0YunaHaD0YundHaD0YunaHaD0YunpHaD0YuntHaD0YuneHaD0YunrHaD0Yun HaD0YuncHaD0YunuHaD0YuntHaD0YunoHaD0YunvHaD0YuneHaD0YunrHaD0Yun HaD0YunsHaD0YuntHaD0YuniHaD0YunlHaD0YunlHaD0Yun HaD0YuncHaD0YunaHaD0YunrHaD0YunrHaD0YuniHaD0YuneHaD0YunsHaD0Yun HaD0YunaHaD0Yun HaD0YunsHaD0YunmHaD0YunaHaD0YunlHaD0YunlHaD0Yun HaD0YunnHaD0YunuHaD0YunmHaD0YunbHaD0YuneHaD0YunrHaD0Yun HaD0YunoHaD0YunfHaD0Yun HaD0YunkHaD0YunnHaD0YunoHaD0YunwHaD0YunnHaD0Yun HaD0YunsHaD0YuneHaD0YunaHaD0YunmHaD0Yun HaD0YungHaD0YunaHaD0YunpHaD0YunsHaD0Yun
-HaD0YuntHaD0YunhHaD0YunaHaD0YuntHaD0Yun HaD0YunaHaD0YunrHaD0YuneHaD0Yun HaD0YuniHaD0YunnHaD0YuntHaD0YuneHaD0YunnHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0YunaHaD0YunlHaD0YunlHaD0YunyHaD0Yun HaD0YuntHaD0YunrHaD0YunaHaD0YuncHaD0YunkHaD0YuneHaD0YundHaD0Yun HaD0YunoHaD0YunuHaD0YuntHaD0YunsHaD0YuniHaD0YundHaD0YuneHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunrHaD0YuneHaD0YunlHaD0YuneHaD0YunaHaD0YunsHaD0YuneHaD0Yun HaD0YungHaD0YunaHaD0YuntHaD0YuneHaD0Yun.HaD0Yun HaD0YunSHaD0YuneHaD0YuneHaD0Yun
-HaD0Yun`HaD0YundHaD0YunoHaD0YuncHaD0YunsHaD0Yun/HaD0YunqHaD0YunaHaD0Yun/HaD0YunrHaD0YunuHaD0YunnHaD0YuntHaD0YuniHaD0YunmHaD0YuneHaD0Yun-HaD0YuntHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunsHaD0YuneHaD0YunaHaD0YunmHaD0Yun-HaD0YunaHaD0YunuHaD0YundHaD0YuniHaD0YuntHaD0Yun-HaD0Yun2HaD0Yun0HaD0Yun2HaD0Yun6HaD0Yun-HaD0Yun0HaD0Yun4HaD0Yun-HaD0Yun0HaD0Yun1HaD0Yun.HaD0YunmHaD0YundHaD0Yun`HaD0Yun HaD0YunfHaD0YunoHaD0YunrHaD0Yun HaD0YuntHaD0YunhHaD0YuneHaD0Yun HaD0YunrHaD0YuneHaD0YunmHaD0YunaHaD0YuniHaD0YunnHaD0YuniHaD0YunnHaD0YungHaD0Yun
-HaD0YunmHaD0YuneHaD0YuntHaD0YunaHaD0YundHaD0YunaHaD0YuntHaD0YunaHaD0Yun-HaD0YunrHaD0YuneHaD0YunsHaD0YunoHaD0YunlHaD0YunuHaD0YuntHaD0YuniHaD0YunoHaD0YunnHaD0Yun HaD0YunaHaD0YunnHaD0YundHaD0Yun HaD0YuncHaD0YunoHaD0YunmHaD0YunpHaD0YunaHaD0YuntHaD0YuniHaD0YunbHaD0YuniHaD0YunlHaD0YuniHaD0YuntHaD0YunyHaD0Yun-HaD0YunrHaD0YuneHaD0YunaHaD0YundHaD0YuneHaD0YunrHaD0Yun HaD0YunfHaD0YunoHaD0YunlHaD0YunlHaD0YunoHaD0YunwHaD0Yun-HaD0YunuHaD0YunpHaD0YunsHaD0Yun.HaD0Yun
-HaD0Yun
+# Rust Runtime Thin-Adapter Release Gate
+
+This gate tracks the release checks for the Rust runtime-core plus thin-adapter lane.
+CI and release validation must fail when any required scenario below is missing or
+failing.
+
+## Verification Matrix
+
+| ID | Scenario | Required evidence | Status |
+|---|---|---|---|
+| G1 | Team status readers survive the manifest-authority compatibility view | `src/compat/__tests__/rust-runtime-compat.test.ts` | [x] |
+| G2 | Doctor preserves manifest-first tmux/session precedence | `src/compat/__tests__/rust-runtime-compat.test.ts` | [x] |
+| G3 | HUD preserves session-scoped state precedence over root fallback | `src/compat/__tests__/rust-runtime-compat.test.ts` | [x] |
+| G4 | Thin-adapter contract docs stay aligned with the reader compatibility lane | `docs/contracts/rust-runtime-thin-adapter-contract.md` + `src/verification/__tests__/rust-runtime-thin-adapter-gate.test.ts` | [x] |
+| G5 | Watcher send-keys parity and mailbox/dispatch paths remain stable after adapter changes | `src/hooks/__tests__/notify-hook-team-dispatch.test.ts` | [x] |
+
+## Pre-mortem Mapping
+
+- Semantic leakage survives into legacy readers:
+  Covered by G1, G2, and G3.
+- Watcher send-keys parity breaks:
+  Covered by G5.
+- Mux contract stays tmux-shaped instead of canonical runtime-shaped:
+  Covered by G4 and the compatibility test lane.
+
+## Required Docs
+
+- `docs/contracts/rust-runtime-thin-adapter-contract.md`
+- `src/compat/__tests__/rust-runtime-compat.test.ts`
+- `src/hooks/__tests__/notify-hook-team-dispatch.test.ts`
+- `src/verification/__tests__/rust-runtime-thin-adapter-gate.test.ts`

package/docs/readme/README.de.md

@@ -25,3 +25,17 @@ See:
 - [../../README.md](../../README.md)
 - [../skills.html](../skills.html)
 - [../reference/roblox-pre-action-protocol.md](../reference/roblox-pre-action-protocol.md)
+
+## Ownership
+
+RCS is owned and maintained by [JustineDevs](https://github.com/JustineDevs) and [@JustineDevs](https://github.com/JustineDevs) for Roblox creator workflows.
+
+## Acknowledgements
+
+- [OpenAI Codex CLI](https://github.com/openai/codex)
+- [oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex)
+- [robloxstudio-mcp](https://github.com/boshyxd/robloxstudio-mcp)
+
+## License
+
+[MIT](https://opensource.org/licenses/MIT)

package/docs/readme/README.el.md

@@ -25,3 +25,17 @@ See:
 - [../../README.md](../../README.md)
 - [../skills.html](../skills.html)
 - [../reference/roblox-pre-action-protocol.md](../reference/roblox-pre-action-protocol.md)
+
+## Ownership
+
+RCS is owned and maintained by [JustineDevs](https://github.com/JustineDevs) and [@JustineDevs](https://github.com/JustineDevs) for Roblox creator workflows.
+
+## Acknowledgements
+
+- [OpenAI Codex CLI](https://github.com/openai/codex)
+- [oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex)
+- [robloxstudio-mcp](https://github.com/boshyxd/robloxstudio-mcp)
+
+## License
+
+[MIT](https://opensource.org/licenses/MIT)