@event4u/agent-config 1.26.0 → 1.28.0

package/.agent-src/commands/e2e-heal.md

@@ -11,6 +11,8 @@ suggestion:
 
 # e2e-heal
 
+> **Mobile scope:** this command targets Playwright (browser/web) tests only. For Detox / Maestro / Appium / XCUITest / Espresso failures, use the `mobile-e2e-strategy` skill plus the framework's own diagnostic tooling — the Playwright-specific steps below do not apply to native mobile.
+
 ## Instructions
 
 ### 1. Identify failing tests

package/.agent-src/commands/e2e-plan.md

@@ -11,6 +11,8 @@ suggestion:
 
 # e2e-plan
 
+> **Mobile scope:** this command targets browser/web E2E only. For native iOS, native Android, or React Native E2E planning, switch to the `mobile-e2e-strategy` skill — Playwright is not the right tool for native UI flows.
+
 ## Instructions
 
 ### 1. Gather context

package/.agent-src/commands/research.md

@@ -0,0 +1,142 @@
+---
+name: research
+cluster: research
+description: "Preliminary research scaffolder — pick objects, define fields, emit `outline.yaml` + `fields.yaml` for downstream deep research. Use for surveys, benchmarks, tech selection, competitive scans."
+disable-model-invocation: true
+skills: [project-analyzer, deep-reading-analyst]
+suggestion:
+  eligible: true
+  trigger_description: "research a topic, scan competitors, benchmark X, do a tech-selection survey"
+  trigger_context: "user names a research topic and wants a structured scaffold (objects + fields), not an immediate answer"
+---
+
+# /research
+
+Entry point for **preliminary research**: pick the objects to study, name
+the fields to fill, and emit a YAML scaffold that a downstream deep-research
+run will populate. Use this when the user names a topic and wants a
+structured plan, not an immediate answer.
+
+Routes thinking-framework support to
+[`deep-reading-analyst`](../skills/deep-reading-analyst/SKILL.md) (SCQA
+for narrative structure, mental-models lens for object selection).
+
+## Trigger
+
+`/research <topic>`
+
+## Workflow
+
+### Step 1 — Initial framework from model knowledge
+
+Generate, from the model's existing knowledge, the candidate object list
+and field framework for the topic:
+
+- **Objects / items** — entities, products, methods, datasets to compare.
+- **Field framework** — dimensions to fill per item (basic info, technical
+  features, evidence, etc.).
+
+Output `{step1_output}` and confirm with the user via numbered options
+(per [`user-interaction`](../rules/user-interaction.md) Iron Law):
+
+1. Add or remove items?
+2. Field framework adequate?
+
+### Step 2 — Web-search supplement
+
+Ask one numbered question for the time range (e.g., last 6 months,
+since 2024, unlimited). Use the agent's native web-search tool — do
+**not** spawn a separate `web-search-agent` persona.
+
+Search prompt template (variables in `{xxx}` only — do not modify
+structure):
+
+```text
+Research topic: {topic}
+Current date: {YYYY-MM-DD}
+Time range: {time_range}
+
+Existing framework:
+{step1_output}
+
+Goals:
+1. Verify existing items are not missing important objects.
+2. Supplement items based on missing objects.
+3. Continue searching for {topic}-related items within {time_range}.
+4. Supplement new fields where helpful.
+
+Output (return inline, do not write files):
+
+### Supplementary items
+- item_name: brief explanation (why it should be added)
+
+### Recommended supplementary fields
+- field_name: field description (why this dimension is needed)
+
+### Sources
+- [Source 1](url)
+- [Source 2](url)
+```
+
+### Step 3 — Existing fields merge
+
+Ask via numbered options whether the user has an existing field-definition
+file. If yes, read the file and merge into the framework before Step 4.
+
+### Step 4 — Generate outline (two files)
+
+Merge `{step1_output}`, `{step2_output}`, and any user-provided fields,
+then write two files into `$PROJECT_ROOT/agents/research/{topic_slug}/`:
+
+**`outline.yaml`** (items + execution config):
+
+- `topic`: research topic
+- `items`: research-objects list
+- `execution`: `batch_size`, `items_per_agent`, `output_dir`
+  (defaults: `./results`; confirm with the user via numbered options)
+
+**`fields.yaml`** (field definitions):
+
+- field categories + definitions
+- per field: `name`, `description`, `detail_level`
+  (`brief` → `moderate` → `detailed`)
+- `uncertain`: list reserved for the deep-research phase
+
+YAML structure validation: see
+[`research-schema`](../contexts/contracts/research-schema.md) for the
+project-local JSON-Schema reference (no runtime Python validator; the
+agent reads the schema and self-validates).
+
+### Step 5 — Output + confirm
+
+Create `agents/research/{topic_slug}/` if absent, write both YAML files,
+and present a summary block to the user:
+
+- Topic + slug.
+- Item count + field count.
+- Path to the two files.
+- Next-step pointer: deep-research orchestration is a follow-up port;
+  use the YAML scaffold as input when that lands.
+
+## Output paths
+
+```text
+$PROJECT_ROOT/agents/research/{topic_slug}/
+  ├── outline.yaml    # items list + execution config
+  └── fields.yaml     # field definitions
+```
+
+## Out of scope (Phase 2)
+
+`/research-deep`, `/research-add-items`, `/research-add-fields`, and the
+Python `validate_json.py` validator are **not** ported in Phase 1 — they
+are queued as follow-up cluster sub-commands.
+
+## ADOPT citation
+
+Adopted from [`Weizhena/Deep-Research-skills`](https://github.com/Weizhena/Deep-Research-skills)
+@ commit `dc18cf4` · upstream file research/SKILL.md inside skills/research-en/ · MIT License.
+Refactored: dropped `web-search-agent` persona (portability), dropped
+Pydantic validator (replaced with JSON-Schema reference), repathed
+`./` → `$PROJECT_ROOT/agents/research/`, deferred `/research-deep` +
+`/research-add-*` to Phase 2.

package/.agent-src/contexts/contracts/frugality-charter.md

@@ -21,9 +21,10 @@ Cite the source rule in writer artifacts; do **not** restate it here.
 
 ## Confirmation taxonomy
 
-Iron-Law / Routine / Contextual classification with carve-outs
-lives in the roadmap [`§ Confirmation taxonomy`](../../../agents/roadmaps/road-to-token-frugality.md#confirmation-taxonomy).
-Charter does not duplicate the table.
+Iron-Law / Routine / Contextual classification with carve-outs is
+canonical in the active token-frugality plate under `agents/roadmaps/`
+(or `agents/roadmaps/archive/` once closed). Charter does not duplicate
+the table.
 
 ## Settings hooks
 

package/.agent-src/contexts/contracts/research-schema.md

@@ -0,0 +1,117 @@
+# research-schema
+
+Project-local JSON-Schema reference for the
+[`/research`](../../commands/research.md) command's two output files —
+`outline.yaml` and `fields.yaml`. The agent reads the schemas below and
+self-validates the YAML before writing; **no runtime Python validator
+ships in this package** — the Pydantic validator from upstream was
+dropped at adoption time and replaced with this reference contract.
+
+## `outline.yaml` schema
+
+```yaml
+# JSON-Schema (YAML form) — outline.yaml
+type: object
+required: [topic, items, execution]
+properties:
+  topic:
+    type: string
+    description: Research topic, free-form.
+  topic_slug:
+    type: string
+    pattern: "^[a-z0-9][a-z0-9-]*$"
+    description: Lower-kebab slug used as the directory name.
+  items:
+    type: array
+    minItems: 1
+    items:
+      type: object
+      required: [name]
+      properties:
+        name: { type: string }
+        explanation: { type: string }
+        source: { type: string, format: uri }
+  execution:
+    type: object
+    required: [batch_size, items_per_agent, output_dir]
+    properties:
+      batch_size:
+        type: integer
+        minimum: 1
+        description: Number of parallel agents in the deep-research phase.
+      items_per_agent:
+        type: integer
+        minimum: 1
+        description: Items each agent processes per batch.
+      output_dir:
+        type: string
+        default: "./results"
+        description: Path (relative to the topic dir) for deep-research output.
+```
+
+## `fields.yaml` schema
+
+```yaml
+# JSON-Schema (YAML form) — fields.yaml
+type: object
+required: [categories]
+properties:
+  categories:
+    type: array
+    minItems: 1
+    items:
+      type: object
+      required: [name, fields]
+      properties:
+        name:
+          type: string
+          description: Category label (e.g., "Basic info", "Technical features").
+        fields:
+          type: array
+          minItems: 1
+          items:
+            type: object
+            required: [name, description, detail_level]
+            properties:
+              name: { type: string }
+              description: { type: string }
+              detail_level:
+                type: string
+                enum: [brief, moderate, detailed]
+  uncertain:
+    type: array
+    description: Reserved field, populated during deep-research phase.
+    items:
+      type: object
+      properties:
+        item: { type: string }
+        field: { type: string }
+        reason: { type: string }
+```
+
+## Self-validation procedure
+
+1. Generate the YAML in memory.
+2. Walk the schema above against the candidate object.
+3. On mismatch, fix the YAML before writing — do not write invalid
+   files and rely on a downstream check.
+4. Validation diagnostics surface to the user inline (file path,
+   field path, expected vs actual). No external dependencies.
+
+## Why no Pydantic / runtime validator
+
+Upstream (`Weizhena/Deep-Research-skills`) shipped a `validate_json.py`
+Pydantic-based validator that assumed `~/.claude/` paths and a Python
+runtime in the consumer environment. Both are
+`augment-portability` violations for this package (zero-runtime-Python
+goal, host-agnostic distribution). The schema reference above lets the
+agent validate by reading; consumers needing programmatic validation
+can pipe the YAML through any JSON-Schema validator they prefer
+(`ajv`, `python-jsonschema`, `check-jsonschema`, etc.).
+
+## Cross-references
+
+- [`/research`](../../commands/research.md) — the command this schema
+  validates.
+- Future `/research:deep` and `/research:report` sub-commands will
+  reference this same schema once ported.

package/.agent-src/rules/domain-adoption-policy.md

@@ -0,0 +1,158 @@
+---
+type: "auto"
+tier: "2b"
+alwaysApply: false
+description: "Adopting a new domain track (mobile, ML, blockchain, IoT, gaming) — gates import on demand, ownership, CI fit, Sunset compatibility BEFORE harvest"
+source: package
+triggers:
+  - intent: "adopt new domain"
+  - intent: "harvest new domain track"
+  - intent: "open a domain plate"
+  - keyword: "mobile track"
+  - keyword: "ml track"
+  - keyword: "blockchain track"
+  - path_prefix: ".agent-src.uncompressed/skills/"
+validator_ignore:
+  - type: "substring"
+    pattern: ".agent-src.uncompressed/"
+    reason: "Rule names the authoring tree as the gated-entry location for new domain plates."
+---
+
+# Domain Adoption Policy
+
+A "domain" is a coherent vertical the suite has not yet entered — mobile, ML,
+blockchain, scientific computing, IoT, gaming, embedded, robotics. Adopting
+one is a structural decision: every new domain plate doubles the surface a
+single maintainer keeps current, and most upstream skill-suites in adjacent
+domains rot within 6-12 months as their underlying SDK churns.
+
+This rule gates that decision. It does **not** gate per-skill adoptions inside
+a domain that is already opened — those run under the regular harvest plate
+process. It gates **opening** the domain in the first place.
+
+## The Iron Law
+
+```
+NEVER OPEN A NEW DOMAIN TRACK WITHOUT THE THREE GATES.
+DEMAND-SIGNAL · NAMED MAINTENANCE OWNER · CI-TOOLING DECISION.
+ALL THREE PASS, OR THE ROADMAP MARKS THE DOMAIN GATED.
+```
+
+The three gates fire before any skill, guideline, command, or rule from the
+domain enters `.agent-src.uncompressed/`. A council session may inform the
+decision but cannot replace the gate evidence.
+
+## Gate 1 — Demand signal
+
+At least one of the following must be **true and citeable** in the roadmap:
+
+- **≥ 2 consumer projects** in the domain. Cite repository names or
+  `agents/contexts/` notes — not "I think there might be".
+- **Named user direction with target.** A specific user ask plus a target
+  project / use case — e.g. "harvest the mobile skills for project X, due
+  next quarter". Vague *"this might be useful"* does not count.
+- **Public-incident pull.** A reproducible incident on a consumer project
+  the domain would have prevented, captured in `agents/contexts/` with
+  the missing surface area named.
+
+If none of the three is citeable, **defer**. Open a watch-only context note
+under `agents/contexts/domain-watch/<domain>.md` listing the missing signal
+so the next harvest can re-evaluate without re-relitigating the case.
+
+## Gate 2 — Named maintenance owner
+
+Domain plates rot. Pick the owner before the import, not after.
+
+- The roadmap names a **single maintainer** (not "the team", not "TBD")
+  responsible for the domain quarterly review.
+- The owner commits to the **refresh cadence** — quarterly review at
+  minimum, faster if the domain is volatile (mobile RN/Expo SDK,
+  ML model APIs).
+- Each adopted artefact carries an **inline upstream-source line** with
+  SHA + last-checked timestamp so refresh is mechanical, not archaeological.
+
+If no owner is named or no cadence is set, **defer**. An unowned domain
+plate becomes broken authoritative-links and stale skills inside two cycles.
+
+## Gate 3 — CI-tooling decision
+
+Either the domain's verification tooling is validated in CI, or the suite
+explicitly accepts platform-bound reference-only status.
+
+- **Validated.** The CI pipeline runs the relevant linters/tests/integration
+  checks for the domain (e.g. `mobile-e2e` runners, ML model validation,
+  contract conformance) on every PR. Cost noted in the roadmap risk
+  register.
+- **Out-of-scope (reference-only).** The domain is a platform fact the
+  suite cannot validate (iOS Simulator on non-macOS runners, GPU-bound
+  ML, hardware-bound IoT). The roadmap states this explicitly; affected
+  artefacts carry a "reference-only on \<unsupported platforms\>" header
+  so consumers do not file false-positive bugs.
+
+If neither line is drawn, **defer**. Half-validated CI silently rots the
+domain — green builds while the underlying tooling drifts.
+
+## Sunset Policy stacks on top
+
+Every domain track inherits the authoritative-link Sunset path documented
+in any plate that imports volatile upstream content:
+
+- Volatile content (SDK-pinned, API-pinned, tool-version-pinned) lives as
+  guideline body + SHA-pinned upstream link, not as forked scripts.
+- Refresh trigger: quarterly cadence or earlier if a SHA-pinned link
+  404s in CI.
+- The `check-refs` and `check-portability` linters apply unchanged.
+
+Adopting a domain does not exempt it from any other suite-wide rule —
+`augment-portability`, `skill-quality`, `size-enforcement`, `docs-sync`,
+`rule-type-governance`. Every domain artefact passes the same gates as a
+core artefact.
+
+## Failure modes
+
+- *"It's just one skill, not a domain."* — Audit the skill's prerequisites.
+  If it pulls in a new toolchain, simulator, language runtime, or
+  platform-specific build system, it **is** a domain entry. Run the gates.
+- *"The upstream is well-maintained, we can just track it."* — Tracking
+  upstream means owning the diff, the breaking changes, and the migrations.
+  Tracking is maintenance work; budget for it under Gate 2 or skip the
+  adoption.
+- *"We'll add CI later."* — Later does not arrive. Either CI is wired in
+  the same plate, or the artefacts ship with explicit reference-only
+  headers so users do not assume validated coverage.
+- *"Council convergence is enough."* — Council informs the gates; it does
+  not replace them. A council session may surface that all three gates
+  pass; the roadmap still cites the evidence.
+- *"Demand-signal is the user asking once."* — Single-shot interest is a
+  watch trigger, not an open trigger. Either name the target use case
+  with project + timeline, or open a watch note and wait.
+
+## What to do when the gates fail
+
+1. Mark the domain plate `[-] gated — <gate name> not met` in the relevant
+   roadmap. Do **not** silently shrink scope to dodge the gate.
+2. Open a watch-only context note under `agents/contexts/domain-watch/`
+   capturing what's missing — citations, owner candidates, CI feasibility.
+3. Re-evaluate at the next harvest cycle. The note is the evidence trail
+   so the same questions are not relitigated.
+
+## Allowed without gates
+
+- Adding **a single skill** to an **already-opened** domain follows the
+  regular harvest plate; the gates do not re-fire per skill.
+- Authoring a **guideline** that documents a domain the suite already
+  ships in — the domain is open, the guideline is a within-domain artefact.
+- A **rule** that constrains an already-opened domain — within-domain.
+
+## See also
+
+- [`augment-portability`](augment-portability.md) — `.agent-src/`
+  must stay project-agnostic; domain plates inherit the floor
+- [`size-enforcement`](size-enforcement.md) — size budgets apply per
+  artefact regardless of domain
+- [`docs-sync`](docs-sync.md) — keep cross-references in sync when
+  opening a domain plate
+- [`rule-type-governance`](rule-type-governance.md) — within-domain rules
+  still pick `always` vs `auto` per the governance table
+- [`skill-quality`](skill-quality.md) — every domain skill passes the
+  same linter floor as a core skill

package/.agent-src/rules/no-roadmap-references.md

@@ -1,7 +1,7 @@
 ---
 type: "auto"
 tier: "mechanical-already"
-description: "Linking transient files (agents/roadmaps/, agents/council-{questions,responses,sessions}/) from a stable artifact — both layers expire; promote findings"
+description: "Linking transient files (agents/roadmaps/, agents/council-*/) from a stable artifact — both layers expire; promote findings"
 alwaysApply: false
 source: package
 triggers:

package/.agent-src/rules/no-unsolicited-rebase.md

@@ -0,0 +1,107 @@
+---
+type: "auto"
+tier: "2a"
+alwaysApply: false
+description: "Working with git history — never rewrite, rebase, squash, fixup, or amend without explicit user request; shape is the user's call, not tidiness"
+source: package
+triggers:
+  - intent: "rebase the branch"
+  - intent: "squash commits"
+  - intent: "clean up commit history"
+  - intent: "fold this into the previous commit"
+  - keyword: "git rebase"
+  - keyword: "fixup"
+  - keyword: "--amend"
+  - keyword: "force-push"
+  - keyword: "squash-merge"
+---
+
+# No Unsolicited Rebase
+
+## Iron Law
+
+```
+NEVER REBASE, SQUASH, FIXUP, OR AMEND PUBLISHED OR LOCAL HISTORY
+WITHOUT THE USER ASKING FOR IT THIS TURN.
+LINEAR HISTORY IS A PREFERENCE, NOT A DEFAULT.
+COMMIT-CHUNK ORDER IS NOT A CORRECTNESS GOAL.
+```
+
+Add the next commit on top. Never reorder, fold, drop, or rewrite earlier
+commits to make the log "look right".
+
+## Why this rule exists
+
+Interactive rebase + fixup loops generate disproportionate token cost on
+every iteration: re-running CI per replayed commit, resolving the same
+content conflict in three derived files (`.compression-hashes.json`,
+`router.json`, `.windsurfrules`), losing the working tree to a stash that
+silently re-introduces older state. A single conflict can burn the budget
+of an entire feature. The user pays for it. The "clean history" payoff is
+cosmetic; reviewers read the diff, not the log.
+
+## When rebase / amend / fixup IS allowed
+
+Exactly three:
+
+1. **User says so this turn** — "rebase onto main", "squash these two",
+   "amend that". This operation only, not a standing rule.
+2. **Standing instruction not yet revoked** — the user said earlier in
+   the conversation "always squash before pushing"; honor it.
+3. **Conflict resolution forced by `git pull --rebase`** — the user
+   already invoked the rebase via pull; finish it.
+
+Anything else — chunk-tidiness, "logical order", folding a follow-up fix
+into its parent — **forbidden**. The follow-up ships as its own commit
+(`fix: …`, `chore: …`).
+
+## Equivalents that are also forbidden by default
+
+- `git rebase -i` (interactive)
+- `git rebase --autosquash`
+- `git commit --fixup` / `--squash` (the helper that feeds the autosquash)
+- `git commit --amend` on already-pushed commits
+- `git push --force` / `--force-with-lease`
+- `git reset --hard` past unpushed work the user might want
+- Squash-merge of a PR via API or CLI when the user has not picked the
+  merge strategy
+- Cherry-pick rewriting that drops or reorders commits
+
+`--amend` on the *current local* commit before the first push is the
+narrow exception (treated as continuing to compose the commit, not
+rewriting history).
+
+## When you'd be tempted
+
+- "I want commit 3 to come before commit 2 because the topic flows better."
+  → don't. Reviewers read the PR diff.
+- "There are two `chore: regenerate` commits, ugly." → don't. They are
+  honest checkpoints.
+- "A linter caught an issue in commit 2 — let me fold the fix in."
+  → don't. Add `fix(scope): …` on top.
+- "I want to drop the WIP commit before pushing." → ask the user first.
+- "Squash-merge when I open the PR will clean it anyway." → also true,
+  also irrelevant — let the merge strategy do that work, not you.
+
+## Failure mode catalog
+
+- **Rebase-conflict cascade.** Interactive rebase replays N commits. Any
+  derived file (`.compression-hashes.json`, generated tool projections,
+  index/catalog) carries a hash per commit and conflicts on every replay.
+  Resolution time scales with N, not with the actual change.
+- **Stash-pop reverts work.** A `git stash` issued during rebase recovery
+  can re-introduce older edits that overwrite committed work after the
+  rebase finishes. Hard to spot in `git status` because the file shapes
+  match.
+- **Force-push during review.** Rewriting history on a branch with an
+  open PR invalidates review comments anchored to commits and forces a
+  re-review.
+
+## See also
+
+- [`scope-control`](scope-control.md) — git-ops permission gate ("rebase"
+  already named in the canonical list).
+- [`commit-policy`](commit-policy.md) — commits are the user's call;
+  rewriting them is a stronger version of the same restriction.
+- [`token-efficiency`](token-efficiency.md) — Iron Law on burning the
+  user's tokens for cosmetic gain.

package/.agent-src/rules/scope-control.md

@@ -28,15 +28,15 @@ The user decides the git shape. Never improvise. Commit specifics: canonical [`c
 - NEVER create / switch / delete a branch without explicit permission — includes spike, scratch, throwaway, worktree branches.
 - NEVER create, close, reopen, or change the target of a pull request without permission.
 - NEVER push a tag or create a release without permission.
-- NEVER include version numbers, target releases, deprecation dates, release-tied milestones, or git tags in roadmaps, plans, tickets, or any planning artifact. Roadmaps plan **work**; releases / tags are a separate decision outside the roadmap. Never surface "which release should this ship in?" as a numbered choice. User pins by saying so explicitly.
+- NEVER include version numbers, target releases, deprecation dates, release-tied milestones, or git tags in roadmaps, plans, tickets, or any planning artifact. Roadmaps plan **work**; releases / tags are a separate decision. User pins by saying so explicitly.
 - Task seems to need a separate branch / PR → STOP and **brief before asking** ([`scope-mechanics § Brief-before-asking`](../contexts/authority/scope-mechanics.md)).
-- BEFORE the first commit on related work, **inventory** existing branches and open PRs (`git branch --show-current`, `gh pr list --state open`). If a plausible base beyond the current branch exists, STOP and ask with numbered options — never improvise the base. Inventory + 4-option template + diverging-stack failure mode: [`scope-mechanics § Branch-base inventory`](../contexts/authority/scope-mechanics.md).
+- BEFORE the first commit on related work, **inventory** existing branches and open PRs. Plausible base beyond the current branch → STOP and ask with numbered options — never improvise. Commands + 4-option template + diverging-stack failure mode: [`scope-mechanics § Branch-base inventory`](../contexts/authority/scope-mechanics.md).
 
 "Explicit permission" = user said so **this turn or in a standing instruction not yet revoked**. Earlier permission for a different operation does not carry over.
 
 ## Production, infrastructure, bulk-destructive — Hard Floor
 
-A subset is **never** autonomous and never auto-permitted by a standing autonomy directive. Canonical: [`non-destructive-by-default`](non-destructive-by-default.md). Trigger list (prod-branch merges, deploys / releases, prod data / infra, bulk-destructive ops) and the "authorization is this turn, not earlier" clarification: [`scope-mechanics § Production, infrastructure, bulk-destructive`](../contexts/authority/scope-mechanics.md).
+A subset is **never** autonomous, regardless of standing autonomy. Canonical: [`non-destructive-by-default`](non-destructive-by-default.md). Triggers (prod-branch merges, deploys, prod data / infra, bulk-destructive) + this-turn-only clarification: [`scope-mechanics § Production, infrastructure, bulk-destructive`](../contexts/authority/scope-mechanics.md).
 
 ## Kernel-rule edits — slow-rollout guarantee
 
@@ -44,11 +44,11 @@ Each kernel-rule edit ships in **its own PR**, ≥ 24 h between merges. Autonomo
 
 ## Decline = silence — no re-asking on the same task
 
-After the user **declines** a proposal (branch switch, PR creation, tag/release entry, separate worktree, version pinning), do **not** raise it again on the same task. Decline stands until the user reopens the topic. Timing / "is this worth asking?": [`scope-mechanics § Decline = silence`](../contexts/authority/scope-mechanics.md).
+After the user **declines** a proposal (branch switch, PR creation, tag/release, separate worktree, version pinning), do **not** raise it again on the same task. Decline stands until reopened. Timing: [`scope-mechanics § Decline = silence`](../contexts/authority/scope-mechanics.md).
 
 ## Fenced step — user-set review gates
 
-User explicitly fences off the next step — *"don't implement yet"*, *"plan only"*, *"just write the roadmap, I'll review"*, *"review first"*, *"erst Roadmap, ich schau drüber"*, *"nichts implementieren"*, *"nur planen"*, *"erstmal nur X, dann ich"* — reply is **the deliverable plus a handoff**, never deliverable plus *"shall we start?"*.
+User explicitly fences off the next step (*"plan only"*, *"review first"*, *"don't implement yet"*, German equivalents) — reply is **deliverable + handoff**, never deliverable + *"shall we start?"*.
 
 ```
 USER FENCED OFF EXECUTION → DELIVER + HAND BACK.
@@ -57,6 +57,4 @@ NO "READY TO IMPLEMENT?" RE-ASK.
 NO "STARTEN WIR MIT PHASE 1?" PIVOT.
 ```
 
-Fence stands until the user reopens, exactly like `Decline = silence`. Permitted follow-up questions cover **the deliverable** (adjust scope, fix wording, add a section), never **its execution**.
-
-Failure-mode catalog (Option 1 = "start now", re-asking after delivery, hand-off-to-execution drift, inferring acceptance from a thumbs-up) and explicit bypass phrases: [`scope-mechanics § Fenced step`](../contexts/authority/scope-mechanics.md).
+Fence stands until reopened (like `Decline = silence`). Follow-ups cover **the deliverable** (scope, wording, sections), never its execution. Failure modes + bypass phrases: [`scope-mechanics § Fenced step`](../contexts/authority/scope-mechanics.md).