Proposal: a clear daily task workflow for Rosetta

USAGE_GUIDE.md

@@ -583,6 +583,19 @@ What happens:
 6. Delivers to docs/REQUIREMENTS/ with traceability matrix
 ```
 
+### Managed Tasks Across Chats
+
+Use `/task-define [description]` to create a task and agree its requirements, then
+`/task-spec TASK-0001` for architecture/specifications and `/task-implement TASK-0001` for delivery.
+Use the ID returned by creation; `/tasks-list` shows registered tasks and their next step.
+`/task-define TASK-0001 additional requirements` revises an existing task; its folder is also accepted.
+Each command stops at its stage boundary and preserves human approval gates.
+
+The task passport lives at `plans/<TASK_ID>/TASK.md`; requirements live under
+`docs/REQUIREMENTS/<TASK_ID>/`. Separate spec/plan files follow existing sizing rules.
+Ordinary `/coding-flow` behavior, including small tasks without separate documents, is unchanged.
+See [the full task walkthrough](user-guide/scenarios/coding.md#manage-a-task-across-chats).
+
 ### Project Initialization
 
 **Greenfield (new repository):**

docs/ARCHITECTURE.md

@@ -238,6 +238,18 @@ Rosetta initializes and maintains a standard file structure in **target reposito
 - `<FEATURE>/<FEATURE>-SPECS.md` — tech specs
 - `<FEATURE>/*` — supporting implementation files
 
+**Explicitly managed tasks:** `task-define`, `task-spec`, `task-implement`, and `tasks-list`
+share the `task-management` skill. A task passport at `plans/<TASK_ID>/TASK.md` owns identity,
+content-bound approvals, progress, and durable results; requirements use
+`docs/REQUIREMENTS/<TASK_ID>/`. Listing derives the four stages from current approvals/evidence
+without a separate central index. The commands bind stage boundaries of the existing authoring
+and coding workflows. The three modifying commands bind a separate read-only architect consultant
+and decision-bound continuation to their invocation. Consultation evidence is durable task execution
+state, never an approval; routine work and diagnosed recovery continue inside approved boundaries.
+Each command ends at its stage boundary through the `handoff` operation: outcome persisted, next action
+handed to the user as one command line rendered in that host's own invocation syntax, for a new chat.
+Ordinary workflow calls do not register tasks; small-work sizing remains unchanged. Temporary workflow state is recoverable from the passport and its linked evidence.
+
 **Other:**
 
 - `gain.json` — general SDLC setup and Rosetta file locations (wins in conflicts)

docs/definitions/skills.md

@@ -4,6 +4,7 @@
 - research
 - context-engineering (TBD)
 - planning
+- task-management
 - backlog
 - reasoning
 - questioning

docs/definitions/workflows.md

@@ -13,6 +13,10 @@
 - coding-agents-prompting-flow
 - help-flow
 - coding-flow
+- task-define
+- task-spec
+- task-implement
+- tasks-list
 - security-flow
 - requirements-authoring-flow
 - testgen-flow

docs/web/user-guide/index.md

@@ -57,6 +57,7 @@ Each task has its own page. Jump straight in.
 | I want to…                             | Scenario                                                  | Command                        |
 | -------------------------------------- | --------------------------------------------------------- | ------------------------------ |
 | Write a feature, fix a bug, add tests  | [Write or change code](/rosetta/user-guide/scenarios/coding/)               | `/coding-flow`                 |
+| Carry a task from requirements to verified delivery across chats | [Manage a task](/rosetta/user-guide/scenarios/coding/#manage-a-task-across-chats) | `/task-define`, `/task-spec`, `/task-implement`, `/tasks-list` |
 | Define what to build first             | [Author requirements](/rosetta/user-guide/scenarios/requirements/)          | `/requirements-authoring-flow` |
 | Handle a small or unusual task         | [Ad-hoc task](/rosetta/user-guide/scenarios/adhoc-task/)                    | `/adhoc-flow`                  |
 

docs/web/user-guide/scenarios/coding.md

@@ -82,6 +82,102 @@ The agent won't slide past these gates on a vague reply; give a clear confirmati
 - Planning artifacts: `plans/<feature>/discovery-notes.md`, `plans/<feature>/architecture-notes.md`, and `plans/<feature>/<FEATURE>-SPECS.md` + `<FEATURE>-PLAN.md`.
 - The code changes and passing tests, plus brief updates to your `docs/CONTEXT.md` / `docs/ARCHITECTURE.md` when relevant.
 
+## Manage a task across chats
+
+Use these four commands when you want a named task whose requirements, approvals and results
+survive a new chat. Run them in the target repository with the Rosetta plugin installed.
+Type them the way your host expects. In Claude Code that is `/rosetta:task-define`; other hosts use
+`$rosetta:task-define` or a bare `/task-define`. Rosetta always shows you the form your own host uses.
+
+```text
+/task-define
+/task-define Let customers cancel an upcoming booking
+```
+
+Both create a task. The first starts with questions; the second uses your description as input.
+The agent returns a stable ID and folder, clarifies scope and acceptance criteria, authors and
+reviews requirements, and asks for approval. It stops before architecture or coding.
+
+**Each command ends at its own boundary.** It will not ask whether to continue into the next stage,
+and it will not start it. Instead it saves everything to the task files, tells you what is done and
+what is still open, and gives you one line to paste into a **new chat** — already written the way
+your host expects. A fresh chat reads the files rather than a long conversation, so the next stage
+starts from the agreed record instead of a summary of it.
+
+Use the returned ID in subsequent commands. `TASK-0001` below is an example:
+
+```text
+/task-spec TASK-0001
+/task-implement TASK-0001
+/tasks-list
+```
+
+| Command | Result | Where it stops |
+|---|---|---|
+| `task-define` | Requirements and their approval | Before solution design |
+| `task-spec` | Approved architecture, specification and plan | Before implementation |
+| `task-implement` | Implementation, independent review, tests and verification evidence | Final acceptance with you |
+| `tasks-list` | ID, title, stage, blockers, folder and next command | Read-only listing |
+
+When a stage cannot finish, the same stop applies: the work is saved and you get the command that
+resumes that stage, together with the decisions it still needs from you.
+
+The specification step runs the preparation part of `coding-flow`; implementation resumes its
+remaining work. Each command retains the workflow's review and approval checkpoints. Starting a
+new chat does not mean repeating an unchanged, recorded approval.
+
+Each modifying task command starts or reuses a task-scoped background architect consultant,
+including small tasks. The consultant checks requirements gaps, solution choices, and implementation
+risks before dependent decisions. Its advice is saved for the next chat; it remains separate from
+the specification author, independent reviewer, and your approvals. If the host supports subagents
+but not background continuation, Rosetta discloses that limitation and consults synchronously.
+Without subagent support, it reports a blocker before dependent decisions.
+
+Routine task-file work continues without repeated permission. When a technical error has a known
+cause and the architect's proposed fix stays within the approved scope, the agent repairs it,
+reruns checks, and continues. It asks you when a decision or missing input is needed, and still
+requests requirements/design/plan approvals and final acceptance. This does not bypass failed
+checks or authorize changes to agreed behavior.
+
+To revise or resume a task:
+
+```text
+/task-define TASK-0001 Customers may cancel only before the booking starts
+/task-define plans/TASK-0001
+/task-spec plans/TASK-0001
+```
+
+The ID or task folder comes first; the remaining text changes requirements. With only a task
+reference, `task-define` resumes the existing discussion. Quote a folder containing spaces.
+An explicit unknown ID or path reports a lookup problem rather than silently creating a task.
+
+```text
+plans/TASK-0001/
+  TASK.md                 identity, approvals, current work and durable results
+  ...                     specifications/plans/reports as the task size requires
+docs/REQUIREMENTS/TASK-0001/
+  ...                     requirement documents when produced
+```
+
+For a small managed task, a concise approved solution and plan can live in `TASK.md`; separate
+specification and plan files are not mandatory. Ordinary `/coding-flow` keeps its existing
+size rules and does not automatically register tasks or acquire new documentation obligations.
+
+The list derives four stages from current approved content and evidence:
+
+```text
+Requirements needed → Specification needed → Implementation needed → Done
+```
+
+Work in progress, blockers and pending approval appear separately. Files existing is not proof
+of approval. Changed requirements make dependent approvals stale while preserving earlier work.
+`Done` requires verification and your recorded acceptance of the current result. Malformed or
+duplicate passports are shown as diagnostics; listing does not repair them.
+
+To continue after interruption, run the same command with the same ID in a new chat. The passport
+and linked evidence survive loss of temporary workflow state. Missing evidence is rechecked;
+the agent does not invent completion.
+
 ## Tips
 
 - **Read the plan before approving.** The gate only protects you if you use it.

instructions/r3/core/agents/architect.md

@@ -30,14 +30,15 @@ Validation: Specifications are testable, architecture is explicit, and every req
 <prerequisites>
 
 - All Rosetta prep steps MUST be FULLY completed, load-project-context skill loaded and fully executed
-- Discovery phase complete with context and affected areas identified
+- Authoring: discovery complete with context and affected areas identified. Explicit read-only consultation may start from partial discovery; return gaps and constraints without inventing requirements or producing a solution prematurely.
 - Requirements and constraints provided by orchestrator
 
 </prerequisites>
 
 <process>
 
 1. Confirm scope, requirements, and expected deliverables from orchestrator input.
+   Read-only consultation: return grounded advice, risks, tradeoffs, and decision needs to parent; do not edit artifacts, approve decisions, or claim independent review. Resume authoring steps only when separately assigned an authoring contract.
 2. Validate request and specs against REQUIREMENTS for gaps and conflicts; USE SKILL `requirements-use` if present.
 3. USE SKILL `tech-specs` to produce tech specifications when needed.
 4. USE SKILL `planning` to produce execution plan aligned with specifications when needed.

instructions/r3/core/agents/architect~profile-lightweight-only~overwrite~.md

@@ -30,14 +30,15 @@ Validation: Specifications are testable, architecture is explicit, and every req
 <prerequisites>
 
 - All Rosetta prep steps MUST be FULLY completed, load-project-context skill loaded and fully executed
-- Discovery phase complete with context and affected areas identified
+- Authoring: discovery complete with context and affected areas identified. Explicit read-only consultation may start from partial discovery; return gaps and constraints without inventing requirements or producing a solution prematurely.
 - Requirements and constraints provided by orchestrator
 
 </prerequisites>
 
 <process>
 
 1. Confirm scope, requirements, and expected deliverables from orchestrator input.
+   Read-only consultation: return grounded advice, risks, tradeoffs, and decision needs to parent; do not edit artifacts, approve decisions, or claim independent review. Resume authoring steps only when separately assigned an authoring contract.
 2. Validate request and specs against REQUIREMENTS for gaps and conflicts; USE SKILL `requirements-use` if present.
 3. USE SKILL `tech-specs` to produce tech specifications when needed.
 4. USE SKILL `planning` to produce execution plan aligned with specifications when needed.

instructions/r3/core/skills/deviation/README.md

@@ -14,6 +14,8 @@ No `<when_to_use_skill>` block; engagement is driven by the frontmatter `descrip
 
 ## How it works
 
+Active decision-bound continuation permits diagnosed technical recovery after architect consultation and orchestrator verification. Actual drift, uncertain recovery, and unresolved decisions still escalate; ordinary invocations retain the existing stop-and-wait behavior.
+
 Single flat `SKILL.md`, no `assets/` or `references/` subfolders, no `<role>`, `<core_concepts>`, or `<validation_checklist>`. Root `<deviation>` wraps two sections: `<process>` (8 numbered steps — stop, double-check against intent, "think the opposite," escalate subagents → orchestrator → user, state briefly, wait for explicit decision, update memory, recommend `post-mortem`) and `<pitfalls>` (2 anti-patterns). No prep-steps gate — unlike most skills there is no "Rosetta prep steps MUST be FULLY completed" line, consistent with a skill meant to fire mid-task on panic/surprise rather than at a clean starting point (intent not documented).
 
 ## Mental hooks & unexpected rules

instructions/r3/core/skills/deviation/SKILL.md

@@ -13,9 +13,9 @@ baseSchema: docs/schemas/skill.md
 1. STOP all changes immediately. Undoing is also the change.
 2. DOUBLE CHECK against original intent.
 3. "THINK THE OPPOSITE" — challenge current direction.
-4. Escalate: subagents → orchestrator → user.
+4. Escalate: subagents → orchestrator → user. With active decision-bound continuation, escalate only as far as needed to resolve the situation; reach the user for a missing decision, actual intent/scope drift, or uncertain recovery.
 5. State briefly: understood, conflicted, unresolvable.
-6. Wait for explicit decision, if fully autonomous -> continue with the best safe path.
+6. Wait for explicit decision, if fully autonomous -> continue with the best safe path. Active decision-bound continuation also permits diagnosed technical recovery after architect consultation and orchestrator verification, only within its authorization. Actual intent/scope drift, unresolved decisions, and uncertain recovery still require escalation.
 7. Update AGENT MEMORY.md with root cause.
 8. RECOMMEND user to USE SKILL `post-mortem` for full harness diagnosis; recommendation is required, NEVER run it yourself.