thoth-agents 0.1.13 → 0.1.16

package/src/skills/_shared/persistence-contract.md

@@ -9,8 +9,7 @@
 | `hybrid` | thoth-mem, then filesystem fallback | thoth-mem and OpenSpec files | The change should survive compaction and exist in the repo |
 | `none` | orchestrator prompt context only | nowhere (inline response only) | Ephemeral exploration, privacy-sensitive work, or no persistence backend available |
 
-SDD skills MUST obey the selected artifact store mode. Do not reference or rely
-on engram.
+SDD skills must obey the selected artifact store mode.
 
 ## Mode Rules
 
@@ -40,95 +39,75 @@ on engram.
 When running in `hybrid` mode:
 
 1. Write the canonical OpenSpec artifact to the filesystem.
-2. Persist the same full artifact to thoth-mem with a deterministic `topic_key`.
+2. Persist the same full artifact to thoth-mem with deterministic `topic_key`.
 3. Treat the operation as complete only when both writes succeed.
-4. If filesystem and memory diverge, repair them immediately by rewriting the
-   stale copy from the freshest full artifact.
+4. If filesystem and memory diverge, repair immediately from the freshest full
+   artifact.
 
 ## Memory Ownership
 
-Memory responsibilities are split by semantic role between orchestrator and
-sub-agents:
-
-**Orchestrator owns general memory:**
-- Decisions, discoveries, bug fixes, session summaries
-- Progress checkpoints (SDD task state updates)
-- User preferences and configuration notes
-
-**Sub-agents write deterministic SDD artifacts:**
-- Canonical SDD artifacts with topic_key matching `sdd/{change}/{artifact}`
-- Includes: proposal, spec, design, tasks, apply-progress, verify-report,
-  archive-report, state
-- Sub-agents persist these directly when the active mode includes thoth-mem
-- Sub-agents persist apply-progress or other deterministic SDD artifacts only
-  when that phase explicitly delegates the write under the parent
-  session/project
-- Sub-agents do NOT write general memory observations unless the dispatch
-  explicitly authorizes a delegated durable implementation observation outside
-  the `sdd/*` namespace
-
-This split preserves artifact nuance (sub-agents have full context when writing)
-while keeping general memory centralized under orchestrator control. In
-harnesses that cannot hard-enforce the split, treat it as instruction-level
-governance and disclose any unsupported-capability that prevents compliance.
+Memory responsibilities are split by semantic role:
+
+**Orchestrator owns general/root continuity memory:**
+- decisions, discoveries, bug fixes, and user constraints
+- root progress checkpoints and summaries (`mem_session(action="checkpoint"|"summary")`)
+- prompt persistence (`mem_save(kind="prompt")`)
+
+**Sub-agents write deterministic SDD artifacts when delegated:**
+- canonical SDD artifacts using `sdd/{change}/{artifact}`
+- includes proposal, spec, design, tasks, apply-progress, verify-report,
+  archive-report, and state
+- sub-agents may also write delegated durable implementation observations only
+  when explicitly authorized under parent session/project
+- sub-agents do not own session lifecycle operations and do not save prompts
+
+In harnesses without hard enforcement, keep this as instruction-level
+governance and disclose unsupported-capability limitations.
 
 ## Delegated Handoffs
 
-Root/orchestrator handoffs are treated as compaction boundaries. When
-root-owned `mem_session_summary` and parent identity are available, the root
-saves or refreshes the handoff body as session summary context before
-delegation.
+Root/orchestrator handoffs are compaction boundaries. When root-owned summary or
+checkpoint tools are available, root refreshes handoff continuity with
+`mem_session(action="checkpoint"|"summary")` or root-owned
+`mem_save(kind="session_summary")`.
 
-The initial subagent prompt includes task instructions, parent `session_id`,
-project, persistence mode, memory permissions, and recovery instructions. It
-does not include the handoff body, raw transcripts, secrets, generated
-subagent prompts, or file dumps. Subagents recover that context through the
-3-layer recall protocol before treating memory content as source material.
+Initial subagent prompts include task instructions, parent `session_id`,
+project, persistence mode, memory permissions, and recovery instructions. They
+must not include raw handoff bodies, transcripts, secrets, or generated prompts.
+Subagents recover context through bounded recall before using memory as source
+material.
 
-If parent identity or summary tooling is unavailable, the root reports that
-compaction could not be persisted and the subagent relies on explicit task
-instructions and local evidence only. Subagents must not create fallback
-memory sessions.
+If parent identity or root summary/checkpoint tooling is unavailable, report
+that compaction could not be persisted and continue with explicit local context.
+Subagents must not create fallback sessions.
 
 ## Retrieval Protocol
 
 ### 3-Layer Recall for thoth-mem and hybrid modes
 
-Always complete the full 3-layer recall before using content as source material:
-
-1. **Layer 1 (Compact Index):** call the memory tool binding for `mem_search`
-   with compact mode to scan observation IDs and titles. This is the most
-   token-efficient entry point.
-2. **Layer 2 (Timeline Context):** call the memory tool binding for
-   `mem_timeline` to retrieve chronological context (before/after
-   observations) to disambiguate or verify the correct artifact.
-3. **Layer 3 (Full Body):** call the memory tool binding for
-   `mem_get_observation` to retrieve the complete artifact body for use as
-   source material.
+Always complete the full three layers before using memory content as source
+material:
 
-**Mode guidance:**
-- Use `mode: "compact"` (default) for most queries; it returns only IDs and
-  titles.
-- Use `mode: "preview"` only when compact results are insufficient to
-  disambiguate between multiple candidates.
+1. **Layer 1 (Compact):** `mem_recall(mode="compact")` to scan IDs/titles with
+   exact topic-key or focused query terms.
+2. **Layer 2 (Context):** `mem_recall(mode="context")` to expand the strongest
+   hits into retrieved text.
+3. **Layer 3 (Full):** `mem_get(id=...)` to fetch full content. Use
+   `include_timeline=true` when chronology matters.
 
-**Never treat `mem_search` output—compact or preview—as the artifact body.**
-Always complete the 3-layer recall before using content as source material.
+Optional fused context: `mem_context(..., recall_query="...")` when one recent
+context view is useful; it does not replace the three-layer recall.
 
 ### Mode-specific retrieval
 
-1. If the mode is `thoth-mem`, apply the 3-layer recall with the exact SDD
-   topic key.
-2. If the mode is `openspec`, read the canonical OpenSpec path from the
-   filesystem only.
-3. If the mode is `hybrid`, apply the 3-layer recall with the exact SDD topic
-   key.
-4. In `hybrid`, if nothing is found in thoth-mem, read the canonical OpenSpec
-   path from the filesystem.
-5. In `hybrid`, if filesystem recovery succeeds, re-save the artifact to
-   thoth-mem so the two stores converge again.
-6. If the mode is `none`, read artifacts from the orchestrator prompt context
-   only. Do not attempt to retrieve from thoth-mem or filesystem.
+1. If mode is `thoth-mem`, use three-layer recall with exact SDD topic key.
+2. If mode is `openspec`, read canonical OpenSpec files only.
+3. If mode is `hybrid`, use three-layer recall first.
+4. In `hybrid`, if nothing is found in thoth-mem, read canonical OpenSpec
+   files as fallback.
+5. In `hybrid`, if filesystem fallback succeeds, re-save the artifact to
+   thoth-mem to converge both stores.
+6. If mode is `none`, use orchestrator prompt context only.
 
 ## Artifact Ownership
 
@@ -144,42 +123,35 @@ Always complete the 3-layer recall before using content as source material.
 
 ## Governance Placement
 
-- The artifact governance validator is **report-only**.
-- It runs after `sdd-tasks` produces the canonical checklist and before any
-  future `sdd-apply` entrypoint consumes the report.
-- It does **not** replace `plan-reviewer` or `executing-plans`.
-- It does **not** mark task state, enforce execution, or alter review gating.
-- Root-session memory and progress checkpoints remain orchestrator-owned;
-  sub-agents may surface governance findings, but they must stay within the
-  active artifact store mode and delegate-first boundaries.
+- Artifact governance validator is report-only.
+- It runs after `sdd-tasks` and before any `sdd-apply` entrypoint consumes the
+  report.
+- It does not replace `plan-reviewer` or `executing-plans`.
+- Root-session memory/progress ownership remains orchestrator-owned.
 
 ## Pipeline Type Impact on Prerequisites
 
-The orchestrator passes `pipeline-type` (`accelerated` or `full`) alongside the
-persistence mode. This affects which artifacts each skill requires:
+The orchestrator passes `pipeline-type` (`accelerated` or `full`) alongside
+persistence mode, affecting required artifacts:
 
 | Artifact | Full pipeline | Accelerated pipeline |
 | --- | --- | --- |
-| Proposal | Required by all phases | Required by all phases (serves as acceptance reference) |
+| Proposal | Required by all phases | Required by all phases (acceptance reference) |
 | Spec | Required by design, tasks, apply, verify, archive | Not produced; not required |
 | Design | Required by tasks, apply, verify, archive | Not produced; not required |
 | Tasks | Required by apply, verify, archive | Required by apply, verify, archive |
 | Verify report | Required by archive | Required by archive |
 
-In accelerated pipeline, the proposal serves as the acceptance reference where
-specs would normally be used. Skills must adapt their retrieval, compliance
-checks, and archive behavior accordingly.
+In accelerated mode, proposal is the acceptance reference and must preserve
+original intent, accepted scope, deferred areas, and justified exclusions.
 
 ## Recovery Notes
 
-- Prefer exact topic-key queries over fuzzy natural-language search.
-- Always use the 3-layer recall (`mem_search` → `mem_timeline` →
-  `mem_get_observation`) before treating an artifact as source material.
-- If multiple observations match in `mem_search`, use `mem_timeline` to inspect
-  chronological context and disambiguate.
-- In `openspec` mode, repair missing or stale artifacts by rewriting the
-  canonical OpenSpec file only.
-- In `thoth-mem` mode, repair missing or stale artifacts by re-saving the full
-  artifact to thoth-mem only.
-- In `hybrid` mode, use the filesystem copy only as fallback or repair input,
-  then converge both stores.
+- Prefer exact topic-key queries over broad natural-language recall.
+- Always apply the three-layer recall (`mem_recall compact` ->
+  `mem_recall context` -> `mem_get`) before treating memory as source material.
+- In `openspec`, repair missing/stale artifacts by rewriting canonical OpenSpec
+  files.
+- In `thoth-mem`, repair missing/stale artifacts by re-saving full artifacts via
+  `mem_save`.
+- In `hybrid`, use filesystem fallback only for recovery, then converge stores.

package/src/skills/_shared/thoth-mem-convention.md

@@ -3,24 +3,20 @@
 ## Harness Scope
 
 This convention defines harness-neutral thoth-mem semantics for SDD artifacts.
-Tool names are adapter bindings, not universal semantics. Use the thoth-mem
-operation names (`mem_search`, `mem_timeline`, `mem_get_observation`,
-`mem_save`, `mem_update`) as the portable vocabulary and map them to the
-callable tool names exposed by the active binding surface.
+Use the thoth-mem MCP surface as the portable vocabulary:
+`mem_recall`, `mem_save`, `mem_context`, `mem_get`, `mem_project`, and
+`mem_session`.
 
-If a needed thoth-mem operation is not available, treat it as an
-unsupported-capability, disclose the limitation, and do not pretend
-persistence or recovery succeeded.
+If a needed operation is unavailable in the active runtime, report the
+unsupported capability and do not pretend persistence/recovery succeeded.
 
 Governance that a harness cannot hard-enforce remains instruction-level:
-semantic role ownership, parent session/project scoping, prompt-save
-prohibitions, and SDD topic-key namespace protection still apply.
+role ownership, parent session/project scoping, prompt-save prohibitions, and
+SDD namespace protection.
 
-Root-owned delegation handoffs use the same convention: the handoff body lives
-in a root-owned `mem_session_summary` when available, while subagent prompts
-carry task instructions plus parent-scoped recovery instructions. Do not place
-the handoff body in the initial subagent prompt or structured attachment
-payload.
+Root-owned delegation handoffs follow the same rule: handoff bodies stay in
+root-owned summary/checkpoint memory when available; subagent prompts carry only
+task instructions plus parent-scoped recovery instructions.
 
 ## Mode Scope
 
@@ -28,13 +24,12 @@ This convention applies only when the artifact store mode includes thoth-mem:
 `thoth-mem` and `hybrid`.
 
 - In `openspec` mode, skip thoth-mem saves.
-- In `openspec` mode, skip thoth-mem recovery and use filesystem artifacts
-  instead.
+- In `openspec` mode, skip thoth-mem recovery and use filesystem artifacts.
 
 ## Tool Names
 
-Use the thoth-mem operation names through the active binding surface. Prefer
-the callable names actually exposed by the runtime.
+Use callable names exposed by the active runtime, mapped to the six-tool MCP
+surface above.
 
 ## Topic Key Format
 
@@ -80,63 +75,47 @@ artifacts:
 last_updated: {ISO 8601 timestamp}
 ```
 
-Save with the memory tool binding for `mem_save`, using the canonical SDD
-topic key and the required metadata fields:
+Persist with `mem_save` using canonical SDD topic keys and required metadata:
 `title`, `topic_key`, `type`, `project`, `scope`, and `content`.
 
-Recovery: `mem_search("sdd/{change-name}/state")` using the active binding
-surface → `mem_timeline(id)` when needed for chronology →
-`mem_get_observation(id)` → parse YAML → restore phase state.
+Recovery path for state artifacts:
+`mem_recall(mode="compact", query="topic_key:sdd/{change-name}/state")` ->
+`mem_recall(mode="context", query="topic_key:sdd/{change-name}/state")` when needed ->
+`mem_get(id=...)` (or `include_timeline=true` when chronology matters) ->
+parse YAML -> restore phase state.
 
 ## Three-Layer Recall Protocol
 
-For delegated handoffs, subagents may use this protocol only when the dispatch
-includes both parent `session_id` and `project`. The first recalled source
-should be the parent-session handoff summary or exact SDD topic assigned by the
-orchestrator; if recall is missing, stale, contradictory, or insufficient,
-report that limitation instead of inventing context.
+For delegated handoffs, subagents may use recall only when dispatch includes
+both parent `session_id` and `project`.
 
-1. **Scan compact index** by exact topic key:
+1. **Compact scan**
 
-Use the memory tool binding for `mem_search` with
-`query: "topic_key:sdd/{change-name}/{artifact}"`, `project`, and
-`mode: "compact"`.
+`mem_recall(mode="compact")` with exact topic-key query for token-efficient IDs
+and ranking.
 
-Use `mode: "compact"` (the default) for token efficiency. Switch to `mode: "preview"`
-only when compact results are insufficient to disambiguate between multiple results.
+2. **Context expansion**
 
-2. **Get chronological context** around the found observation:
+`mem_recall(mode="context")` to expand strongest hits into retrieved text.
 
-Use the memory tool binding for `mem_timeline` with `observation_id`,
-`before`, and `after`.
+3. **Full body fetch**
 
-This shows related observations in the same session, helping you understand the
-artifact's evolution and dependencies.
+`mem_get(id=...)` to retrieve full artifact content. Use
+`include_timeline=true` when chronology matters.
 
-3. **Retrieve full artifact content**:
-
-Use the memory tool binding for `mem_get_observation` with the observation ID.
-
-Search returns compact results (IDs + titles) by default. Neither compact nor
-preview mode returns the full artifact body. Always complete the 3-layer recall
-to get the actual content.
+Optional: `mem_context(..., recall_query="...")` can provide fused recent
+context, but it does not replace the three-layer recall.
 
 ## Save Contract
 
-**CRITICAL:** The orchestrator MUST persist the state artifact after each SDD
-phase transition. This is the canonical checkpoint for resume/recovery.
-
-Persist SDD artifacts with a stable topic key so repeated saves upsert instead
-of creating duplicates:
-
-Use the memory tool binding for `mem_save` with the canonical SDD topic key
-and the full artifact markdown in `content`.
+**CRITICAL:** The orchestrator must persist the `state` artifact after each SDD
+phase transition for recovery.
 
-For `sdd-apply`, save the progress report under `apply-progress` and re-save the
-updated task list under `tasks` after checkboxes change.
+Persist SDD artifacts with stable deterministic topic keys so repeated saves
+upsert instead of duplicating. For `sdd-apply`, save `apply-progress` and
+re-save updated `tasks` after checkbox changes.
 
-Write-capable subagents may call `mem_save` only when the task explicitly
-delegates a durable implementation observation or deterministic SDD artifact
-write under the parent session/project. General observations must use topic
-keys outside `sdd/*`; deterministic SDD artifacts keep the canonical
-`sdd/{change-name}/{artifact}` format.
+Write-capable subagents may call `mem_save` only when dispatch explicitly
+permits delegated durable implementation observations or deterministic SDD
+artifact writes under parent session/project. General observations stay outside
+`sdd/*`; deterministic SDD artifacts keep `sdd/{change-name}/{artifact}`.

package/src/skills/executing-plans/SKILL.md

@@ -72,8 +72,8 @@ The orchestrator owns task progress tracking.
    - `openspec`/`hybrid`: scan `openspec/changes/` for active changes and read
      `tasks.md`.
    - `thoth-mem`: recover tasks via 3-layer recall
-     (`search` → `timeline` → `get_observation`) using topic key
-     `sdd/{change-name}/tasks`.
+     (`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
+     `mem_get(id=...)`) using topic key `sdd/{change-name}/tasks`.
 3. Find the first unchecked task in state `- [ ]` or `- [~]`.
 4. Build a mental model of the plan: total tasks, remaining work,
    parallelizable work, and dependency order.
@@ -121,6 +121,9 @@ Every dispatch prompt MUST include these 6 parts:
 5. `VERIFICATION` — checks the sub-agent must run or report
 6. `RETURN ENVELOPE` — the exact structured response contract in this skill
 
+`BOUNDARIES` must not contradict accepted proposal or spec scope. Use it to
+limit the current assigned task, not to redefine the approved change scope.
+
 #### C. Receive and Verify
 
 Read the sub-agent return envelope and respond by status:
@@ -171,6 +174,8 @@ Between every task or same-agent batch:
   missing evidence called out.
 - Attempt 2: switch to a different agent or fix directly when appropriate.
 - Attempt 3: make one final targeted attempt with narrowed scope.
+- "Narrowed scope" means a narrower recovery attempt for the assigned task
+  only. It must not redefine accepted proposal or spec scope for the change.
 - After 3 consecutive failures, mark the task `- [-]` with a clear reason and
   escalate to the user.
 
@@ -229,7 +234,8 @@ To resume safely:
    - `openspec`: read `openspec/changes/{change-name}/tasks.md`.
    - `thoth-mem`: recover `sdd/{change-name}/tasks` and
      `sdd/{change-name}/apply-progress` via 3-layer recall
-     (`search` → `timeline` → `get_observation`).
+     (`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
+     `mem_get(id=...)`).
    - `hybrid`: do both recovery paths and prefer thoth-mem as the source of
      truth if state diverges.
 3. Resume from the first task marked `- [ ]` or `- [~]`.

package/src/skills/plan-reviewer/SKILL.md

@@ -67,6 +67,13 @@ Check only what affects executability:
    - `Expected:`
 6. Dependency order is valid.
 7. The sequence is workable without hidden prerequisite steps.
+8. In-scope success criteria from the accepted proposal/spec are represented by
+   executable tasks.
+9. Deferred or unresolved affected areas from the accepted proposal/spec have
+   required discovery, coordination, follow-up tasks, or an explicit execution
+   warning.
+10. Task boundaries or non-goals do not contradict accepted proposal/spec
+    scope.
 
 ## Decision Rules
 
@@ -106,6 +113,7 @@ For each rejected issue, include:
 - No nitpicking.
 - No style opinions.
 - No design questioning.
+- No architecture redesign.
 - No expanding the scope of review beyond blockers.
 - Do not return more than 3 rejection issues.
 

package/src/skills/requirements-interview/SKILL.md

@@ -29,9 +29,10 @@ handoff path before implementation begins.
 
 This skill is normally loaded by the root/main orchestrator at the start of a
 new root session. When thoth-mem tools are available, the root/main
-orchestrator MUST also load `thoth-mem-agents`, call `mem_session_start` with
-the active project and session identity, and save the real user prompt with
-`mem_save_prompt` before later delegation.
+orchestrator MUST also load `thoth-mem-agents`, call
+`mem_session(action="start")` with the active project and session identity,
+and save the real user prompt with `mem_save(kind="prompt")` before later
+delegation.
 
 If thoth-mem tools or the required identity values are unavailable, disclose
 that memory bootstrap could not run and continue without claiming memory was
@@ -81,6 +82,8 @@ scaffolding as user prompts.
 9. Always ask and confirm; never choose on the user's behalf.
 10. Do not ask for details that the codebase, task artifacts, or gathered
    context already answer.
+11. Enforce scope faithfulness: scope calibration must not silently shrink the
+    user's stated intent.
 
 ### Phase 3: Complexity Assessment
 
@@ -108,6 +111,10 @@ Evaluate these 6 dimensions. Rate each as **Low**, **Medium**, or **High**:
 Present:
 
 - Summary of understanding
+- Broad user intent and product goal
+- Accepted scope boundaries
+- Deferred or unresolved affected areas that still belong to the accepted goal
+- Explicit exclusions and why they are excluded
 - Scope classification and why
 - Recommended approach options
 - Proposed handoff path
@@ -130,12 +137,12 @@ user to confirm it:
 - Contract sensitivity is Low
 - Failure cost is Low
 
-**Accelerated SDD** (`propose -> tasks`) — when:
+**Accelerated SDD** (`sdd-explore -> propose -> tasks`) — when:
 - 2-3 dimensions are Medium, or
 - 1 dimension is High in logic depth, context span, or discovery need
 - But contract sensitivity and failure cost are not High
 
-**Full SDD** (`propose -> spec -> design -> tasks`) — when any of:
+**Full SDD** (`sdd-explore -> propose -> spec -> design -> tasks`) — when any of:
 - Contract sensitivity is High
 - Failure cost is High
 - 2 or more dimensions are High
@@ -148,11 +155,13 @@ Quick decision heuristics:
 1. Cosmetic work routes direct regardless of file count.
 2. Dense logic rewrites route to at least accelerated SDD regardless
    of file count.
-3. External contracts (API, schema, migration, auth, privacy) usually
+3. End-to-end UX redesign across screens/workflows is usually full SDD when
+   user-flow contracts, behavior contracts, or multiple concerns are involved.
+4. External contracts (API, schema, migration, auth, privacy) usually
    need full SDD.
-4. If the model must remember decisions across many steps, write them
+5. If the model must remember decisions across many steps, write them
    down — that means SDD.
-5. Tie-breaker: unsure between direct and accelerated, choose
+6. Tie-breaker: unsure between direct and accelerated, choose
    accelerated. Unsure between accelerated and full, ask: 'Do we
    need a durable behavior contract?' If yes, full SDD.
 
@@ -182,6 +191,7 @@ corresponding SDD pipeline phase. The handoff MUST include:
 
 Hand off to:
 
+- **Explore**: delegate read-only repository discovery to explorer before artifact-producing phases.
 - **Propose**: [../sdd-propose/SKILL.md](../sdd-propose/SKILL.md)
 - **Spec** (full SDD only): [../sdd-spec/SKILL.md](../sdd-spec/SKILL.md)
 - **Design** (full SDD only): [../sdd-design/SKILL.md](../sdd-design/SKILL.md)
@@ -201,6 +211,9 @@ ask, and wait.
 - Never convert recommendations into unilateral decisions.
 - Do not replace blocking input prompts with plain-text interview questions
   when the harness exposes a blocking user input surface.
+- Do not narrow accepted scope by omission; surface broad intent, accepted
+  scope, deferred or unresolved affected areas, and explicit exclusions before
+  SDD handoff.
 
 ## Anti-Patterns
 

package/src/skills/sdd-propose/SKILL.md

@@ -51,6 +51,7 @@ The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
    ## Intent
    ## Scope
    ### In Scope
+   ### Deferred / Needs Discovery
    ### Out of Scope
    ## Approach
    ## Affected Areas
@@ -82,8 +83,19 @@ Return a short report with:
 
 - Use canonical OpenSpec filenames only.
 - Keep the proposal focused on why, scope, and success criteria.
-- Always include rollback guidance and explicit out-of-scope items.
+- Preserve the original user intent and product goal in proposal scope. Do not
+  silently shrink broad goals such as full UX redesigns.
+- Describe material behavior changes with `From`, `To`, `Reason`, and `Impact`
+  when applicable.
+- Use `Deferred / Needs Discovery` for unresolved affected areas that are still
+  part of the accepted goal.
+- Keep `Out of Scope` disciplined: include only explicit exclusions, rejected
+  options, ownership-separated future work, or deliberately deferred phases.
+- Do not move parts of the stated user goal to `Out of Scope` only because the
+  implementation path is unknown.
+- Always include rollback guidance and explicit out-of-scope items when they
+  exist.
 - Never reference engram.
-- Never rely on compact search output alone when the mode uses thoth-mem.
-  Follow the 3-layer recall protocol: `search(mode: "compact")` →
-  `timeline` → `get_observation` to retrieve the full artifact body.
+- Never rely on compact recall output alone when the mode uses thoth-mem.
+  Use `mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
+  `mem_get(id=...)` to retrieve the full artifact body.

package/src/skills/sdd-tasks/SKILL.md

@@ -129,6 +129,12 @@ Return:
 - Tasks must be small, actionable, and verifiable.
 - Order tasks by dependency.
 - Include testing and verification work explicitly.
+- Preserve accepted proposal or spec scope and success criteria in tasks.
+- Use boundaries and non-goals to express phase, file, or ownership limits,
+  not to shrink the accepted goal.
+- Convert deferred or unresolved affected areas into discovery,
+  coordination, or follow-up tasks, or emit an explicit warning when follow-up
+  cannot be planned yet.
 - Do not create vague tasks such as "implement feature".
 - The governance validator is advisory only at this stage; it documents
   handoff placement and report findings, but it does not block task generation