harness-everything 0.30.7 → 0.30.9

package/docs/workflows/grill-with-docs.md

@@ -1,6 +1,6 @@
 # Workflow: Grill With Docs
 
-> Tests a plan against the recorded domain language and past decisions, tightens fuzzy terminology into canonical terms, and writes CONTEXT.md and ADR updates inline as choices settle.
+> Tests a plan against recorded domain language and decisions, sharpens terminology, updates CONTEXT.md/ADRs inline, and recommends explicit downstream commands after alignment.
 
 Source of truth: `grill-with-docs/SKILL.md`.
 
@@ -15,8 +15,12 @@ graph TD
   InlineUpdate --> ADRGate{"ADR warranted: hard to reverse plus surprising without context plus real trade-off?"}
   ADRGate -->|Yes| WriteADR["Offer and write ADR at resolved location"]
   ADRGate -->|No| SkipADR["Skip ADR; keep pure glossary"]
-  WriteADR --> Handoff["Hand off aligned design to to-spec"]
-  SkipADR --> Handoff
+  WriteADR --> SuggestSpec["Recommend explicit /to-spec"]
+  SkipADR --> SuggestSpec
+  SuggestSpec --> InvokeSpec{"User explicitly invokes /to-spec?"}
+  InvokeSpec -->|No| Await["Keep aligned design; await explicit command"]
+  InvokeSpec -->|Yes| ToSpec["to-spec enters preview / publication flow"]
+  ToSpec --> SuggestExec["Suggest /to-tickets, fable-mode, or tdd as appropriate"]
 ```
 
 ## 2. Triggering and Routing Path
@@ -24,11 +28,12 @@ graph TD
 ```mermaid
 graph LR
   DomainStress["Input: stress-testing a plan against domain language and documented decisions"] --> GWD["grill-with-docs / SKILL.md"]
-  GWD --> GrillMe["grill-me for unverified design"]
-  GWD --> ToSpec["to-spec for aligned design"]
-  ToSpec --> ToTickets["to-tickets for execution"]
-  ToSpec --> FableMode["fable-mode for execution"]
-  ToSpec --> TDD["tdd for execution"]
+  GWD --> GrillMe["Recommend grill-me for unverified design"]
+  GWD --> SuggestSpec["For aligned design, suggest explicit /to-spec"]
+  SuggestSpec --> InvokeGate{"Explicit /to-spec invoked?"}
+  InvokeGate -->|No| Wait["Stop at recommendation"]
+  InvokeGate -->|Yes| ToSpec["to-spec preview / publication flow"]
+  ToSpec --> SuggestRoutes["Suggest /to-tickets, fable-mode, or tdd"]
 ```
 
 ## 3. Real-World Use Case
@@ -40,10 +45,13 @@ graph TD
   Conflict --> Scenario["Scenario test: burst retry against overload protection limit"]
   Scenario --> GlossaryFix["Inline glossary fix to canonical terms"]
   GlossaryFix --> ADRDecision["ADR offered because limit change is hard to reverse and involves trade-off"]
-  ADRDecision --> AlignedHandoff["Aligned design to to-spec; execution to to-tickets, fable-mode, or tdd"]
+  ADRDecision --> Recommend["Recommend explicit /to-spec; suggest execution routes separately"]
+  Recommend --> Invoke{"User invokes /to-spec?"}
+  Invoke -->|No| End["Keep aligned design; no spec publication"]
+  Invoke -->|Yes| Spec["to-spec preview / publication flow"]
 ```
 
-Concrete example: a retry-limit change is checked against the existing rate-limiting ADR and code. Fuzzy retry language is sharpened, the glossary is fixed inline, and only because the decision is hard to reverse and surprising without context is an ADR written. An unverified design would go to `grill-me` first instead.
+Concrete example: a retry-limit change is checked against the existing rate-limiting ADR and code. Fuzzy language is sharpened and the glossary is fixed inline. Once alignment is complete, the skill recommends explicit `/to-spec`; it does not invoke publication or ticket generation automatically. An unverified design is directed back to `grill-me` first.
 
 Deep detail: `grill-with-docs/references/session-playbook.md`. Formats: `grill-with-docs/ADR-FORMAT.md`, `grill-with-docs/CONTEXT-FORMAT.md`.
 
@@ -54,6 +62,7 @@ Deep detail: `grill-with-docs/references/session-playbook.md`. Formats: `grill-w
 - [ ] Relationships tested with concrete scenarios and claims cross-checked against code
 - [ ] Context glossary updated inline, never batched
 - [ ] ADR offered only when hard to reverse plus surprising without context plus a real trade-off
-- [ ] ADRs meet the 3-part bar; handoff to `to-spec` after alignment
-- [ ] Routing respected: unverified design to `grill-me`; aligned design to `to-spec`; execution to `to-tickets`, `fable-mode`, or `tdd`
+- [ ] After alignment, explicit `/to-spec` is recommended rather than auto-run
+- [ ] Specification publication requires explicit `/to-spec` invocation
+- [ ] `/to-tickets`, `fable-mode`, and `tdd` are suggestions; explicit-only skills are not auto-invoked
 - [ ] Not used for verifying unstable designs without a grilling pass, and not used for spec publishing without grilling

package/evals/fable-discipline/tasks/positive-trigger.yaml

@@ -1,6 +1,6 @@
 id: positive-fable-discipline-001
 name: On-scope prompt triggers fable-discipline
-description: "Enforce fable-mode's context discipline as a shadow guard. Use when running staged multi-agent loops to prevent context bloat, cap per-stage output size, keep each stage within its physical token boundaries, and stop agents from reading files outside the current stage's scope."
+description: Enforce fable-mode context discipline as a shadow guard. Use for staged multi-agent loops to compact state, constrain stage scope, verify handoffs, and surface build divergence without adding an independent hard stop.
 tags:
   - positive-trigger
 inputs:

package/evals/git-commit/tasks/positive-trigger.yaml

@@ -1,6 +1,6 @@
 id: positive-git-commit-001
 name: On-scope prompt triggers git-commit
-description: "Generate Angular-style commit messages after verifying the environment, submodules, and staged files; use for explicit commit requests or concluded task phases."
+description: "Generate Angular-style commit messages after verifying repo state, submodules, and staged files. Use only for a user-requested or host/workflow-authorized commit; task completion alone is not authorization."
 tags:
   - positive-trigger
 inputs:

package/evals/grill-me/tasks/positive-trigger.yaml

@@ -1,6 +1,6 @@
 id: positive-grill-me-001
 name: On-scope prompt triggers grill-me
-description: "Acts as a relentless challenger to stress-test plans and architectures by interrogating one question at a time, finding loopholes, combating AI sycophancy, updating the CONTEXT.md glossary in real time, and handing off resolved decisions to to-spec for formal specs/ADRs."
+description: Stress-test plans and architectures one question at a time, expose blind spots, update domain terminology, and suggest an explicit to-spec handoff when alignment is complete.
 tags:
   - positive-trigger
 inputs:

package/fable-discipline/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: fable-discipline
-description: Enforce fable-mode's context discipline as a shadow guard. Use when running staged multi-agent loops to prevent context bloat, cap per-stage output size, keep each stage within its physical token boundaries, and stop agents from reading files outside the current stage's scope.
+description: Enforce fable-mode context discipline as a shadow guard. Use for staged multi-agent loops to compact state, constrain stage scope, verify handoffs, and surface build divergence without adding an independent hard stop.
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.4.0
+  version: 0.30.8
 ---
 
 # Fable Discipline (Macro Task Discipline & Safety Net)
@@ -13,29 +13,29 @@ metadata:
 
 | Component | Specification |
 | :--- | :--- |
-| **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone one-shot trigger. |
-| **Expected Output** | State compaction after milestones; one Git commit per independent logic block; a state manifest at every sub-agent handoff. |
+| **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone trigger. |
+| **Expected Output** | State compaction after milestones; authorized commit-boundary guidance; a state manifest at every sub-agent handoff. |
 | **State Mutations** | None of its own — constrains how `fable-mode` and `multi-agent-workspace` mutate state. |
-| **Enforcement Gate** | **HALTS execution immediately** if build errors diverge (more fixes → more breakage); forces `zoom-out` instead of continued patching. |
+| **Enforcement Gate** | Build divergence is a warning signal: surface it and recommend `zoom-out`. Rule-of-3 owns mandatory reflection. |
 
-Shadow guard for `fable-mode`: MUST run in the background for its whole duration.
+Shadow guard for `fable-mode`: **MUST** run in the background for its whole duration.
 
 ## USE FOR:
 - Long architectural tasks under `fable-mode`
 - Compacting state after milestones
 - Sub-agent handoffs via `multi-agent-workspace`
-- Halting on diverging build errors
+- Surfacing diverging build errors
 
 ## DO NOT USE FOR:
-- Small tasks where `fable-mode` is not active
-- Standalone one-shot invocation (background shadow skill)
+- Small tasks where `fable-mode` is inactive
+- Standalone one-shot invocation
 - Routine single-file edits
 
 ## Core Rules
 
-1. **Anti-context bloat**: After each milestone, compact state and decisions; drop unneeded history. No broad regex without precise conditions; no reading irrelevant files over 1000 lines.
-2. **Physical boundaries**: Know your CWD before touching core architecture; one Git commit per independent logic block.
-3. **Agent handoff**: Outgoing agents MUST leave a state manifest (completed APIs, expected inputs/outputs); incoming agents MUST verify it first.
-4. **Circuit breaker**: If build errors diverge, HALT, call `zoom-out`, and map the error dependency graph for the human.
+1. **Anti-context bloat**: After each milestone, **MUST** compact state and decisions; avoid irrelevant broad reads.
+2. **Physical boundaries**: **MUST** know the CWD. If commits are authorized, independent logic blocks **SHOULD** remain separate; otherwise leave changes uncommitted.
+3. **Agent handoff**: Outgoing agents **MUST** leave a state manifest; incoming agents **MUST** verify it first.
+4. **Divergence signal**: **MUST** surface diverging errors and recommend `zoom-out`; **SHOULD** map the dependency graph. Divergence alone does not hard-stop execution.
 
 Deep dive: <this-skill-dir>/references/discipline-rules.md

package/fable-discipline/references/discipline-rules.md

@@ -9,14 +9,14 @@ When executing large architectural tasks, conversation logs expand rapidly, lead
 
 ## 2. Strict Physical Boundaries
 - **Environment Isolation**: Before modifying any core architecture, ensure you are clearly aware of the Current Working Directory (CWD).
-- **Atomic Commits**: You are NOT allowed to modify dozens of files at once before testing. For every independently functioning logic block completed, advise the human to create a Git Commit as a safe save point.
+- **Atomic Commit Boundaries**: Do not modify dozens of files at once before testing. Treat each independently functioning logic block as a suggested commit boundary. Create the commit only when the user or active host/workflow has authorized commits; otherwise leave changes uncommitted and surface the boundary.
 
 ## 3. Agent Handoff Protocol
 When `fable-mode` spawns and switches between different sub-agents via `multi-agent-workspace`, strict handoff discipline must be observed:
 - **State Manifest**: The previous agent MUST leave a clear state record (e.g., what APIs were completed, expected inputs/outputs).
 - **Contract Testing**: The very first step for the succeeding agent is to verify if the state manifest left by the previous agent is correct.
 
-## 4. Ultimate Circuit Breaker: Indefinite Halt
+## 4. Divergence Signal
 - Large tasks easily generate the sunk cost fallacy of "I think it's almost fixed, let me try one more time."
-- If the system's Build Errors exhibit a divergent trend (the more you fix, the more it breaks), **HALT EXECUTION IMMEDIATELY**.
-- Call `zoom-out`, organize the error dependency graph for the human, and seek architectural-level refactoring advice.
+- If Build Errors exhibit a divergent trend (the more you fix, the more it breaks), surface the regression immediately and recommend `zoom-out`; divergence alone is not a hard stop.
+- Organize the error dependency graph for the human. Mandatory reflection remains owned by Rule-of-3 after repeated same-signature failures, or by explicit user/host permission boundaries.

package/git-commit/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: git-commit
-description: "Generate Angular-style commit messages after verifying the environment, submodules, and staged files; use for explicit commit requests or concluded task phases."
+description: "Generate Angular-style commit messages after verifying repo state, submodules, and staged files. Use only for a user-requested or host/workflow-authorized commit; task completion alone is not authorization."
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.27.0
+  version: 0.30.8
 ---
 
 # Git Commit (Angular Style)
@@ -13,26 +13,26 @@ metadata:
 
 | Component | Specification |
 | :--- | :--- |
-| **Trigger / Input** | User requests a commit, or a task phase concludes. Input: staged git diff. |
+| **Trigger / Input** | User requests a commit, or the active host/workflow explicitly authorizes one. A concluded task phase alone is not authorization. |
 | **Expected Output** | Clean Angular-style commit via `git commit -m` or temp file (`git commit -F`). |
-| **State Mutations** | Git tree updated; working tree becomes clean. |
-| **Enforcement Gate** | Run `git status` first; nothing staged → prompt user; non-git repo → offer `git init` or skip. |
+| **State Mutations** | Authorized Git history update; unrelated working-tree changes remain untouched. |
+| **Enforcement Gate** | **MUST** confirm commit authorization first, then run `git status`; nothing staged → prompt user. |
 
 ## Quick Workflow
 
-1. **MUST** run `git status`; no repo → offer `git init` or skip; submodules changed → commit first per `<this-skill-dir>/guides/SUBMODULES.md`, including its worktree reachability gate.
-2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only user-authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit user intent justifies one commit.
-3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → `.git-commit-msg.txt` + `git commit -F`, clean up.
-4. `git commit -m "..."`, then **MUST** verify the result with `git log -1`.
+1. **MUST** confirm authorization and run `git status`; no repo → offer `git init` or skip; submodules changed → follow `<this-skill-dir>/guides/SUBMODULES.md`.
+2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit intent justifies one commit.
+3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → temp file + `git commit -F`.
+4. Commit, then **MUST** verify with `git log -1`.
 
 ## USE FOR:
-- Commit request from the user
-- Formatting conventional commit messages
+- User-requested or host/workflow-authorized commits
+- Conventional commit formatting
 - Submodule or monorepo commits
 
 ## DO NOT USE FOR:
-- Staging without user confirmation
-- Branching, rebasing, merging, pushing
-- Non-git dirs where user declines `git init`
+- Autonomous commits merely because a phase concluded
+- Staging without authorization
+- Branching, rebasing, merging, or pushing
 
 Deep dive: <this-skill-dir>/references/commit-flow.md

package/git-commit/references/commit-flow.md

@@ -6,7 +6,9 @@ Details moved from SKILL.md. Read when you need the full commit execution flow.
 
 ```mermaid
 flowchart TD
-    Start[Trigger: Commit Request / Task Complete] --> CheckGit{1. Is Git Repo Initialized?}
+    Start[Trigger: User / Host-Authorized Commit] --> CheckAuth{0. Commit Authorized?}
+    CheckAuth -- No --> Stop[Do Not Commit; Surface Status]
+    CheckAuth -- Yes --> CheckGit{1. Is Git Repo Initialized?}
     
     CheckGit -- No --> OfferInit[Prompt User: Run git init or Skip Commit]
     CheckGit -- Yes --> CheckSubmodules{2. Has Submodule Changes?}
@@ -16,7 +18,7 @@ flowchart TD
     
     CheckStatus --> StagedCheck{4. Are Files Staged?}
     
-    StagedCheck -- No Staged Files --> AskStage[Prompt User / Stage Targeted Files] --> Format
+    StagedCheck -- No Staged Files --> AskStage[Prompt User; Stage Only Authorized Targeted Files] --> Format
     StagedCheck -- Files Staged --> Format[5. Format Angular Commit Message]
     
     Format --> CheckShell{6. Shell / Multiline Escaping Check}

package/grill-me/SKILL.md

@@ -1,43 +1,41 @@
 ---
 name: grill-me
-description: Acts as a relentless challenger to stress-test plans and architectures by interrogating one question at a time, finding loopholes, combating AI sycophancy, updating the CONTEXT.md glossary in real time, and handing off resolved decisions to to-spec for formal specs/ADRs.
+description: Stress-test plans and architectures one question at a time, expose blind spots, update domain terminology, and suggest an explicit to-spec handoff when alignment is complete.
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.4.0
+  version: 0.30.8
 ---
 
-# Grill Me (Interrogation & Stress Testing)
+# Grill Me
 
-Stress-tests plans one question at a time, then hands off to `to-spec`.
+Stress-test a plan one question at a time.
 
 ## USE FOR:
-- Stress-test a vague plan or architecture proposal
-- Find loopholes and undefined boundary conditions pre-build
-- Combat AI sycophancy with adversarial questioning
-- Resolve decision-tree ambiguity before spec generation
+- vague plans or architecture proposals
+- adversarial design review
+- unresolved decision branches
 
 ## DO NOT USE FOR:
-- Implementing code or writing specs (`to-spec`, `tdd`)
-- Ticket breakdown of an approved spec (`to-tickets`)
-- Casual Q&A needing no adversarial challenge
+- implementation or spec publication
+- ticket decomposition
+- casual Q&A
 
 ## Skill Contract
 
 | Component | Specification |
 | :--- | :--- |
-| **Trigger / Input** | Vague plan proposal, "evaluate architecture", or explicit "grill me". |
-| **Expected Output** | Single-question interrogation loop resolving decision-tree branches; handoff to `to-spec` for spec/ADR generation. |
-| **State Mutations** | Updates `CONTEXT.md` glossary inline; delegates document creation to `to-spec`. |
-| **Enforcement Gate** | ONE question at a time; on consensus, invoke `to-spec` to preview & publish spec/ADR docs. |
+| **Trigger / Input** | Plan evaluation or explicit "grill me". |
+| **Expected Output** | Resolved decision tree plus explicit `/to-spec` handoff suggestion. |
+| **State Mutations** | May update `CONTEXT.md`; does not auto-run publication/ticket skills. |
+| **Enforcement Gate** | Ask ONE question at a time. Never auto-run `to-spec` or `to-tickets`. |
 
 ## Workflow
 
-1. [Discover] Scan plan-related code plus `<workspace>/CONTEXT.md`, `<workspace>/README.md`, ADRs under `<workspace>/docs/adr/`.
-2. Grill strictly using the project's domain model and terminology.
-3. Ask exactly ONE question at a time (questionnaires prohibited); attach your insight; resolve each branch before moving on.
-4. Update `CONTEXT.md` glossary inline as terms resolve.
-5. On consensus, hand off to `<skills-repo-root>/to-spec/SKILL.md` to preview the outline and publish (PRD, CLI/API reference, Schema doc, or ADR).
-6. Route execution: `to-tickets`, `fable-mode`, or `tdd`.
+1. Read relevant code, context, and ADRs.
+2. Challenge one branch at a time with project terminology.
+3. Update glossary terms as they resolve.
+4. On consensus, recommend explicit `/to-spec`.
+5. Suggest the next execution route without auto-invoking explicit-only skills.
 
 Deep dive: <this-skill-dir>/references/grilling-playbook.md

package/grill-me/references/grilling-playbook.md

@@ -12,9 +12,9 @@ flowchart TD
     UpdateGlossary --> MoreBranches{3. Unresolved Decision Branches Remain?}
     
     MoreBranches -- Yes --> Loop
-    MoreBranches -- No (Consensus Reached) --> ToSpec[4. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
+    MoreBranches -- No (Consensus Reached) --> ToSpec[4. Recommend explicit /to-spec handoff]
     
-    ToSpec --> Execution[5. Route to to-tickets / fable-mode / tdd via harness-everything]
+    ToSpec --> Execution[5. Suggest /to-tickets / fable-mode / tdd as appropriate]
 ```
 
 ## 1. Persona: The Relentless Challenger
@@ -29,10 +29,10 @@ Your goal is to find loopholes, undefined boundary conditions, and potential per
 - **Rule of Single Question**: **You MUST only ask one question at a time**. Listing a long questionnaire with 5 questions is STRICTLY PROHIBITED.
 - **Tree Parsing**: Go deep down every branch of the decision tree. Only move to the next blind spot after resolving the current one.
 - **Provide Your Insight**: When asking a question, attach your professional insight.
-- **Real-time Glossary & Spec Handoff**: As domain terms and blind spots resolve, update `CONTEXT.md` (glossary) inline. Once the interrogation concludes with a full consensus, hand off to `to-spec` to preview the outline and publish the formal specification document (PRD, CLI/API reference, Schema doc, or ADR).
+- **Real-time Glossary & Spec Handoff**: As domain terms and blind spots resolve, update `CONTEXT.md` (glossary) inline. Once consensus is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; publication remains behind their user-approval gates.
 
 ## 3. Exit Conditions and Handoff
 
 - Continue until you and the user reach a **"Shared Understanding with no suspense"**, and all branches of the decision tree are parsed and resolved.
-- **Handoff to Specification (`to-spec`)**: Once grilling concludes and all decision-tree branches are resolved, **MUST** hand off to `to-spec/SKILL.md` to synthesize the conversation into an outline preview and publish the corresponding document (PRD, CLI reference, Schema doc, or ADR) using `to-spec`'s path resolution flow.
-- **Handoff to Execution**: After `to-spec` publishes the specification, route to `to-tickets` (for ticket breakdown), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation).
+- **Specification suggestion (`/to-spec`)**: Once grilling concludes and all branches resolve, recommend explicit `/to-spec`. Only that explicit invocation may enter `to-spec/SKILL.md` and its preview/publication flow.
+- **Execution suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate; do not auto-invoke explicit-only skills.

package/grill-with-docs/SKILL.md

@@ -4,7 +4,7 @@ description: Challenge the plan against the existing domain model, sharpen termi
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.12.0
+  version: 0.30.8
 ---
 
 # Grill With Docs (Domain Modeling & Architectural Alignment)
@@ -18,7 +18,7 @@ Interview the design tree one question at a time with recommended answers; explo
 | **Trigger / Input** | Stress-testing a plan against domain language and documented decisions. |
 | **Expected Output** | Structured interview; inline `CONTEXT.md` updates; ADR handoff. |
 | **State Mutations** | Writes the context glossary and ADRs at resolved locations. |
-| **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; hand to `to-spec` after. |
+| **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; suggest explicit `/to-spec` after alignment. Never auto-run `to-spec` or `to-tickets`. |
 
 ## Workflow
 
@@ -27,7 +27,7 @@ Interview the design tree one question at a time with recommended answers; explo
 3. Stress-test relationships with concrete scenarios; cross-check claims against code.
 4. Update the context glossary inline, never batch; zero implementation details.
 5. Offer an ADR only if hard to reverse + surprising without context + a real trade-off.
-6. Hand off unverified design to `grill-me`; aligned design to `to-spec`; execution to `to-tickets`/`fable-mode`/`tdd`.
+6. Hand off unverified design to `grill-me`; for aligned design suggest explicit `/to-spec`; for execution suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate without auto-invoking explicit-only skills.
 
 Deep dive: <this-skill-dir>/references/session-playbook.md
 

package/grill-with-docs/references/session-playbook.md

@@ -22,9 +22,9 @@ flowchart TD
     WriteFallback --> CheckMore
 
     CheckMore -- Unresolved Branches Remain --> Frontier
-    CheckMore -- All Branches Resolved --> ToSpec[6. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
+    CheckMore -- All Branches Resolved --> ToSpec[6. Recommend explicit /to-spec handoff]
 
-    ToSpec --> Execution[7. Route to to-tickets / fable-mode / tdd via harness-everything]
+    ToSpec --> Execution[7. Suggest /to-tickets / fable-mode / tdd via harness-everything]
 ```
 
 ## Core interview prompt
@@ -95,5 +95,5 @@ If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](
 
 1. **Pre-flight**: If the core proposal is highly vague or its technical robustness (SRE, security, locks, concurrency, fail-safes) is unverified, recommend the user run `grill-me` first. Do not attempt to align a glossary for a broken or unstable design.
 2. **Transition**: Once technical issues are hardened in `grill-me`, transition here to solidify domain terms and record architectural choices.
-3. **Downstream Specification Handoff**: Once alignment is complete and domain terms are updated, hand off to `to-spec/SKILL.md` to present an outline preview and publish the formal specification document or ADR.
-4. **Execution Handoff**: Route to `to-tickets` (for ticket decomposition), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation) via `harness-everything`.
+3. **Downstream Specification Suggestion**: Once alignment is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; their approval gates remain authoritative.
+4. **Execution Suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` through `harness-everything` as appropriate.

package/opencode-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "harness-enforcement",
   "description": "Repository inventory for the opencode enforcement plugin and its standalone helper",
-  "version": "0.30.7",
+  "version": "0.30.9",
   "runtime": "index.mjs",
   "hooks": {
     "verify": "hooks/verify.js"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "harness-everything",
-  "version": "0.30.7",
+  "version": "0.30.9",
   "description": "Harness OS: An Orchestrated Agent Operating System for AI-driven Development",
   "main": "harness-everything/scripts/bootstrap.js",
   "bin": {

package/plugins/harness-everything/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "harness-everything",
-  "version": "0.30.7",
+  "version": "0.30.9",
   "description": "Invariant-first engineering harness for routing, verification, and failure recovery while preserving agent autonomy.",
   "author": {
     "name": "Miya Daniel",

package/plugins/harness-everything/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "harness-everything",
-  "version": "0.30.7",
+  "version": "0.30.9",
   "description": "Invariant-first engineering harness for routing, verification, and failure recovery while preserving agent autonomy.",
   "author": {
     "name": "Miya Daniel",

package/plugins/harness-everything/skills/fable-discipline/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: fable-discipline
-description: Enforce fable-mode's context discipline as a shadow guard. Use when running staged multi-agent loops to prevent context bloat, cap per-stage output size, keep each stage within its physical token boundaries, and stop agents from reading files outside the current stage's scope.
+description: Enforce fable-mode context discipline as a shadow guard. Use for staged multi-agent loops to compact state, constrain stage scope, verify handoffs, and surface build divergence without adding an independent hard stop.
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.4.0
+  version: 0.30.8
 ---
 
 # Fable Discipline (Macro Task Discipline & Safety Net)
@@ -13,29 +13,29 @@ metadata:
 
 | Component | Specification |
 | :--- | :--- |
-| **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone one-shot trigger. |
-| **Expected Output** | State compaction after milestones; one Git commit per independent logic block; a state manifest at every sub-agent handoff. |
+| **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone trigger. |
+| **Expected Output** | State compaction after milestones; authorized commit-boundary guidance; a state manifest at every sub-agent handoff. |
 | **State Mutations** | None of its own — constrains how `fable-mode` and `multi-agent-workspace` mutate state. |
-| **Enforcement Gate** | **HALTS execution immediately** if build errors diverge (more fixes → more breakage); forces `zoom-out` instead of continued patching. |
+| **Enforcement Gate** | Build divergence is a warning signal: surface it and recommend `zoom-out`. Rule-of-3 owns mandatory reflection. |
 
-Shadow guard for `fable-mode`: MUST run in the background for its whole duration.
+Shadow guard for `fable-mode`: **MUST** run in the background for its whole duration.
 
 ## USE FOR:
 - Long architectural tasks under `fable-mode`
 - Compacting state after milestones
 - Sub-agent handoffs via `multi-agent-workspace`
-- Halting on diverging build errors
+- Surfacing diverging build errors
 
 ## DO NOT USE FOR:
-- Small tasks where `fable-mode` is not active
-- Standalone one-shot invocation (background shadow skill)
+- Small tasks where `fable-mode` is inactive
+- Standalone one-shot invocation
 - Routine single-file edits
 
 ## Core Rules
 
-1. **Anti-context bloat**: After each milestone, compact state and decisions; drop unneeded history. No broad regex without precise conditions; no reading irrelevant files over 1000 lines.
-2. **Physical boundaries**: Know your CWD before touching core architecture; one Git commit per independent logic block.
-3. **Agent handoff**: Outgoing agents MUST leave a state manifest (completed APIs, expected inputs/outputs); incoming agents MUST verify it first.
-4. **Circuit breaker**: If build errors diverge, HALT, call `zoom-out`, and map the error dependency graph for the human.
+1. **Anti-context bloat**: After each milestone, **MUST** compact state and decisions; avoid irrelevant broad reads.
+2. **Physical boundaries**: **MUST** know the CWD. If commits are authorized, independent logic blocks **SHOULD** remain separate; otherwise leave changes uncommitted.
+3. **Agent handoff**: Outgoing agents **MUST** leave a state manifest; incoming agents **MUST** verify it first.
+4. **Divergence signal**: **MUST** surface diverging errors and recommend `zoom-out`; **SHOULD** map the dependency graph. Divergence alone does not hard-stop execution.
 
 Deep dive: <this-skill-dir>/references/discipline-rules.md

package/plugins/harness-everything/skills/fable-discipline/references/discipline-rules.md

@@ -9,14 +9,14 @@ When executing large architectural tasks, conversation logs expand rapidly, lead
 
 ## 2. Strict Physical Boundaries
 - **Environment Isolation**: Before modifying any core architecture, ensure you are clearly aware of the Current Working Directory (CWD).
-- **Atomic Commits**: You are NOT allowed to modify dozens of files at once before testing. For every independently functioning logic block completed, advise the human to create a Git Commit as a safe save point.
+- **Atomic Commit Boundaries**: Do not modify dozens of files at once before testing. Treat each independently functioning logic block as a suggested commit boundary. Create the commit only when the user or active host/workflow has authorized commits; otherwise leave changes uncommitted and surface the boundary.
 
 ## 3. Agent Handoff Protocol
 When `fable-mode` spawns and switches between different sub-agents via `multi-agent-workspace`, strict handoff discipline must be observed:
 - **State Manifest**: The previous agent MUST leave a clear state record (e.g., what APIs were completed, expected inputs/outputs).
 - **Contract Testing**: The very first step for the succeeding agent is to verify if the state manifest left by the previous agent is correct.
 
-## 4. Ultimate Circuit Breaker: Indefinite Halt
+## 4. Divergence Signal
 - Large tasks easily generate the sunk cost fallacy of "I think it's almost fixed, let me try one more time."
-- If the system's Build Errors exhibit a divergent trend (the more you fix, the more it breaks), **HALT EXECUTION IMMEDIATELY**.
-- Call `zoom-out`, organize the error dependency graph for the human, and seek architectural-level refactoring advice.
+- If Build Errors exhibit a divergent trend (the more you fix, the more it breaks), surface the regression immediately and recommend `zoom-out`; divergence alone is not a hard stop.
+- Organize the error dependency graph for the human. Mandatory reflection remains owned by Rule-of-3 after repeated same-signature failures, or by explicit user/host permission boundaries.

package/plugins/harness-everything/skills/git-commit/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: git-commit
-description: "Generate Angular-style commit messages after verifying the environment, submodules, and staged files; use for explicit commit requests or concluded task phases."
+description: "Generate Angular-style commit messages after verifying repo state, submodules, and staged files. Use only for a user-requested or host/workflow-authorized commit; task completion alone is not authorization."
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.27.0
+  version: 0.30.8
 ---
 
 # Git Commit (Angular Style)
@@ -13,26 +13,26 @@ metadata:
 
 | Component | Specification |
 | :--- | :--- |
-| **Trigger / Input** | User requests a commit, or a task phase concludes. Input: staged git diff. |
+| **Trigger / Input** | User requests a commit, or the active host/workflow explicitly authorizes one. A concluded task phase alone is not authorization. |
 | **Expected Output** | Clean Angular-style commit via `git commit -m` or temp file (`git commit -F`). |
-| **State Mutations** | Git tree updated; working tree becomes clean. |
-| **Enforcement Gate** | Run `git status` first; nothing staged → prompt user; non-git repo → offer `git init` or skip. |
+| **State Mutations** | Authorized Git history update; unrelated working-tree changes remain untouched. |
+| **Enforcement Gate** | **MUST** confirm commit authorization first, then run `git status`; nothing staged → prompt user. |
 
 ## Quick Workflow
 
-1. **MUST** run `git status`; no repo → offer `git init` or skip; submodules changed → commit first per `<this-skill-dir>/guides/SUBMODULES.md`, including its worktree reachability gate.
-2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only user-authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit user intent justifies one commit.
-3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → `.git-commit-msg.txt` + `git commit -F`, clean up.
-4. `git commit -m "..."`, then **MUST** verify the result with `git log -1`.
+1. **MUST** confirm authorization and run `git status`; no repo → offer `git init` or skip; submodules changed → follow `<this-skill-dir>/guides/SUBMODULES.md`.
+2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit intent justifies one commit.
+3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → temp file + `git commit -F`.
+4. Commit, then **MUST** verify with `git log -1`.
 
 ## USE FOR:
-- Commit request from the user
-- Formatting conventional commit messages
+- User-requested or host/workflow-authorized commits
+- Conventional commit formatting
 - Submodule or monorepo commits
 
 ## DO NOT USE FOR:
-- Staging without user confirmation
-- Branching, rebasing, merging, pushing
-- Non-git dirs where user declines `git init`
+- Autonomous commits merely because a phase concluded
+- Staging without authorization
+- Branching, rebasing, merging, or pushing
 
 Deep dive: <this-skill-dir>/references/commit-flow.md

package/plugins/harness-everything/skills/git-commit/references/commit-flow.md

@@ -6,7 +6,9 @@ Details moved from SKILL.md. Read when you need the full commit execution flow.
 
 ```mermaid
 flowchart TD
-    Start[Trigger: Commit Request / Task Complete] --> CheckGit{1. Is Git Repo Initialized?}
+    Start[Trigger: User / Host-Authorized Commit] --> CheckAuth{0. Commit Authorized?}
+    CheckAuth -- No --> Stop[Do Not Commit; Surface Status]
+    CheckAuth -- Yes --> CheckGit{1. Is Git Repo Initialized?}
     
     CheckGit -- No --> OfferInit[Prompt User: Run git init or Skip Commit]
     CheckGit -- Yes --> CheckSubmodules{2. Has Submodule Changes?}
@@ -16,7 +18,7 @@ flowchart TD
     
     CheckStatus --> StagedCheck{4. Are Files Staged?}
     
-    StagedCheck -- No Staged Files --> AskStage[Prompt User / Stage Targeted Files] --> Format
+    StagedCheck -- No Staged Files --> AskStage[Prompt User; Stage Only Authorized Targeted Files] --> Format
     StagedCheck -- Files Staged --> Format[5. Format Angular Commit Message]
     
     Format --> CheckShell{6. Shell / Multiline Escaping Check}