Refine sheet dismissal, add cortex list, update docs

UX & behavior: Add route-dismiss logic and a dismissible prop to SheetContent (ROUTE_DISMISS_PROGRESS threshold, onRouteDismiss callback, swipe/escape/click handling), simplify overlay rendering, and expose frontmost to WorkbenchSheet so only the frontmost sheet is dismissible/overlayed and shows the close button. Styling: adjust sheet sizing/positioning in globals.css to use fixed right/width and full-width behavior. Feature: render cortex frames in DispatchSheet by importing cortexEventsFromTranscript and adding a RuntimeItem list with onOpenCortex. Docs/config: strengthen review/self-check guidance in SKILL.md and code-review SKILL.md, add a guidance line to AGENTS.md, and add .codex/config.toml with project markers and doc size limit. Misc: minor typings and imports cleanup across components.

Author: romanonthego

.agents/skills/agent-self-check/SKILL.md

@@ -29,6 +29,8 @@ These checks have higher authority than "tests passed." Passing tests do not mak
 
 Fix these directly when they are in your changed code. If fixing one would change public behavior, package exports, persisted data handling, or compatibility, stop and report it as a deferred concern instead of silently preserving or deleting it.
 
+For each issue you find, name the mechanism before fixing it. Do not patch symptoms by adding local conditionals, broad fallbacks, or compatibility wrappers unless that is the intended design.
+
 ### Modeling
 
 - closed protocol/domain/state handling written as if/else return soup instead of exhaustive `Match` or `switch` with a `never` check

.agents/skills/code-review/SKILL.md

@@ -22,15 +22,26 @@ Do not rewrite code during a review unless the user asks for fixes. If you find
 
 Treat the checklist below as review gates, not taste notes. If changed code violates one, either file a finding or explicitly explain why the local context makes it acceptable.
 
+Review diagnosis must identify the mechanism, not just the symptom. Prefer:
+
+- observation: what the diff/code/test shows
+- inference: what mechanism likely produced it
+- prescription: what change removes the mechanism
+- measurement: what check proves the fix
+
+For recurring problems, use the frame: signal, loop, constraint, intervention, measurement.
+
 ## Finding Format
 
 For each finding, include:
 
 - priority: `P0`, `P1`, `P2`, or `P3`
 - confidence: `C0`, `C1`, `C2`, or `C3`
 - tight file/line reference
-- why it matters
-- what should change
+- observation: the concrete evidence
+- mechanism: why it creates risk
+- prescription: what should change
+- measurement: what would verify the fix
 
 Order findings by severity. Keep summaries secondary.
 

.agents/skills/docs-reading/SKILL.md

@@ -40,7 +40,8 @@ the conflict if it affects the task.
 - Core primitives: `docs/primitives/primitives.md`, plus the specific note
   such as `tool.md` or `agent-comm.md`.
 - Runtime: `docs/runtime/architecture.md`,
-  `docs/runtime/mission-system.md`, and `docs/runtime/isolation.md`.
+  `docs/runtime/mission-system.md`, `docs/runtime/isolation.md`,
+  `docs/maps/runtime-truth-map.md`, and `docs/maps/not-real-yet.md`.
 - Server: read runtime docs first, then server package code; server is a host
   adapter, not runtime owner.
 - Client/operator surfaces: `docs/clients/README.md` and runtime command,

.agents/skills/roadmap-management/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: roadmap-management
+description: Use when creating, updating, reviewing, or promoting Theseus roadmap items, including public roadmap notes, internal roadmap status maps, planning lanes, GitHub issue readiness, and OSS roadmap hygiene.
+---
+
+# Theseus Roadmap Management
+
+Use this skill when roadmap or planning work changes what Theseus says it is
+building next.
+
+Roadmap work is status management, not aspiration capture. Keep current truth,
+planned work, research, and rejected paths separate.
+
+## Read Order
+
+Start with:
+
+1. `docs/direction/roadmap.md`
+2. `docs/maps/roadmap-status-map.md`
+3. `docs/maps/runtime-truth-map.md`
+4. `docs/maps/not-real-yet.md`
+5. the owning concept note for the roadmap item
+
+If an item concerns implementation, verify against source before marking it
+`shipped`, `active`, or `next`.
+
+## Roadmap Artifacts
+
+- `docs/direction/roadmap.md`: concise public-facing roadmap.
+- `docs/maps/roadmap-status-map.md`: internal evidence table and promotion state.
+- GitHub issues: execution units only after the item is actionable.
+- GitHub milestones/projects: sequencing containers, not doctrine.
+
+Do not put loose ideation in the roadmap. Move it to `docs/brainstorms` or
+`docs/drafts` first.
+
+## Status Vocabulary
+
+Use one status per item:
+
+- `shipped`: implemented and verified.
+- `active`: currently being built.
+- `next`: intended soon and clear enough to plan.
+- `designed`: accepted direction, not scheduled.
+- `research`: needs investigation, prototype, or decision.
+- `blocked`: dependency or unresolved decision is known.
+- `parked`: not rejected, but not worth attention now.
+- `rejected`: deliberately not doing.
+
+Avoid `future`. It hides whether an item is designed, research, blocked, or
+parked.
+
+## Promotion Pipeline
+
+```text
+brainstorm -> draft -> designed -> next -> active -> shipped
+```
+
+Promotion rules:
+
+- Do not promote directly from brainstorm to active.
+- Do not mark `next` without a `done when` test.
+- Do not mark `active` without an owner and evidence that work has started.
+- Do not mark `shipped` unless code, tests/checks, and docs agree.
+- When promoting or demoting, update `roadmap-status-map.md` in the same pass.
+
+## Item Shape
+
+Every roadmap-ready item needs:
+
+- status
+- owner
+- source docs
+- evidence or current implementation note
+- dependency or blocker, if any
+- `done when` criteria
+
+If `done when` cannot be written, the item belongs in `research`, `drafts`, or
+`brainstorms`, not `next`.
+
+## OSS Posture
+
+For public docs:
+
+- Prefer `Now / Next / Later / Not Planned` over dates.
+- Publish less than the internal status map knows.
+- State non-promises explicitly.
+- Do not imply timelines unless the project intends to carry timeline pressure.
+- Keep roadmap items tied to user-visible or contributor-visible value.
+
+## Verification
+
+After roadmap doc edits, run:
+
+```sh
+bun run docs:check
+```
+
+Use `docs-management` rules for links, frontmatter, folder placement, and
+status separation.

.codex/config.toml

@@ -0,0 +1,2 @@
+project_root_markers = ["bun.lock", "package.json", "AGENTS.md"]
+project_doc_max_bytes = 65536

AGENTS.md

@@ -114,6 +114,7 @@ Treat these as the conceptual base unless current code or docs prove otherwise:
 - IDs crossing package, persistence, tool, RPC, dispatch, or mission boundaries should be branded/schema-backed, not raw `string`.
 - If ordering matters, encode it in the API. Do not rely on incidental object key order, registration order, import order, or array order.
 - Logs, capsules, dispatch events, protocol events, and telemetry are append-only unless an explicit compaction/snapshot boundary says otherwise.
+- Define expected outcome, success criteria, allowed side effects, evidence rules, and stopping conditions before changing complex or high-risk code. Avoid step-by-step process scaffolding unless the exact path matters.
 
 ### Module Shape
 
@@ -171,6 +172,8 @@ Use `code-review` when reviewing code changes for defects, regressions, missing
 
 Use `cleanup-audit` after substantial edits, refactors, moves, generated changes, or long agent sessions to remove confirmed non-behavioral leftovers and report possible stale compatibility/runtime paths before changing them.
 
+Use `roadmap-management` when creating, updating, reviewing, or promoting roadmap items.
+
 </skills>
 
 <generated-files>

docs/README.md

@@ -41,3 +41,5 @@ This `docs/` directory is the Theseus Obsidian vault.
 - Move superseded designs to `archive/` instead of deleting them.
 - Keep stable doctrine in the concept note; put time-bound reasoning in `design-notes/`.
 - Run `bun run docs:check` after docs moves or link edits.
+- Use [runtime-truth-map](maps/runtime-truth-map.md) and [not-real-yet](maps/not-real-yet.md) before changing runtime docs.
+- Use [roadmap](direction/roadmap.md) and [roadmap-status-map](maps/roadmap-status-map.md) for planning work.

docs/direction/README.md

@@ -12,4 +12,5 @@ Direction notes define what Theseus is for and what constraints the system is bu
 ## Notes
 
 - [goals](goals.md)
+- [roadmap](roadmap.md)
 - [agent-comm-prior-art](agent-comm-prior-art.md)

docs/direction/roadmap.md

@@ -0,0 +1,72 @@
+---
+status: current
+owner: direction
+kind: concept
+updated: 2026-04-29
+---
+
+# Roadmap
+
+> Status: active planning shell
+
+This roadmap describes the intended shape of Theseus work. It is conservative:
+it separates what exists, what is practical next, what is designed but not
+scheduled, and what is deliberately not planned.
+
+Use [roadmap-status-map](../maps/roadmap-status-map.md) for the internal
+evidence table.
+
+## Now
+
+Work that should make the current coding harness more controllable,
+inspectable, recoverable, or usable.
+
+| Item | Status | Why It Matters |
+|---|---|---|
+| Runtime work tree visibility | next | Operators need truthful mission work state before richer clients can be useful. |
+| Capsule event curation | next | Mission outputs need a durable review-facing record, not only raw runtime events. |
+| Thin server/runtime boundary | next | Runtime behavior should stay owned by `packages/theseus-runtime`, with server as adapter. |
+| First operator client surface | research | `docs/clients` has no active concept note yet; client work needs a narrow first shape. |
+
+## Next
+
+Designed or likely near-term work that needs sharper scope before execution.
+
+| Item | Status | Why It Matters |
+|---|---|---|
+| Mission hardening | designed | Raw user intent needs a path into dispatchable missions without forcing ceremony on small tasks. |
+| Tool selection and catalog clarity | designed | Tool authority needs explicit selection and hydration before broader autonomy. |
+| Pause and resume safe points | designed | Runtime should reserve cooperative control semantics without pretending it can freeze arbitrary work. |
+| RuntimeBus transport concept | designed | Client/operator surfaces need transport vocabulary, but it must adapt to command/control/query. |
+
+## Later
+
+Research or larger architecture work that should not block the near-term
+runtime wedge.
+
+| Item | Status | Why It Matters |
+|---|---|---|
+| Cortex context management | research | Context durability and recall may become important after event/projection surfaces stabilize. |
+| Semantic or tool-result folding | research | Folding needs evidence from real failure bursts before becoming runtime doctrine. |
+| Outcome execution beyond coding | research | The primitives should support this ambition, but the wedge remains coding harness first. |
+
+## Not Planned
+
+These paths are not active roadmap items.
+
+| Item | Reason |
+|---|---|
+| Plugin marketplace or generic plugin host | Theseus is a self-editable harness with explicit source assembly. |
+| Persistent named-agent daemon runtime | Superseded by the current runtime host/world model. |
+| Fixed crew roster as architecture | Crew and specialist roles are harness scaffolding, not primitive floor. |
+| Queue RuntimeBus as the runtime base | Superseded by runtime command/control/query. |
+
+## Rules
+
+- Do not promote a roadmap item without updating
+  [roadmap-status-map](../maps/roadmap-status-map.md).
+- Do not mark work as shipped unless implementation, tests/checks, and docs
+  agree.
+- Do not use dates unless the project accepts date pressure.
+- Keep loose ideas in [brainstorms](../brainstorms/README.md) and unadopted
+  designs in [drafts](../drafts/README.md).

docs/maps/README.md

@@ -13,3 +13,6 @@ that should be read before changing code or design.
 ## Notes
 
 - [coding-agent-reading-map](coding-agent-reading-map.md)
+- [runtime-truth-map](runtime-truth-map.md)
+- [not-real-yet](not-real-yet.md)
+- [roadmap-status-map](roadmap-status-map.md)