diff --git a/.opencode/agents/gaze-reporter.md b/.opencode/agents/gaze-reporter.md index e21ba19..ab40b1e 100644 --- a/.opencode/agents/gaze-reporter.md +++ b/.opencode/agents/gaze-reporter.md @@ -5,6 +5,7 @@ description: > metrics, side effect classifications, and overall project health. Supports three modes: crap (CRAP scores only), quality (test quality metrics only), and full (comprehensive health assessment). +mode: subagent tools: read: true bash: true @@ -12,7 +13,7 @@ tools: edit: false webfetch: false --- - + # Gaze Reporter Agent diff --git a/.opencode/agents/gaze-test-generator.md b/.opencode/agents/gaze-test-generator.md index 532bcfe..ca5a487 100644 --- a/.opencode/agents/gaze-test-generator.md +++ b/.opencode/agents/gaze-test-generator.md @@ -5,6 +5,7 @@ description: > complete, compilable Go test functions, improve documentation for classifier visibility, and restructure assertions for mapper accuracy. Works on any Go project gaze can analyze. +mode: subagent tools: read: true bash: true @@ -12,7 +13,7 @@ tools: edit: true webfetch: false --- - + # Role: Test Generator @@ -251,7 +252,10 @@ For each target function, output: 3. **File target**: Which `*_test.go` file to write to 4. **Verification**: Whether the code compiles and tests pass -After generating all code, run: +After generating all code, run a final integrity check across all +modified packages. Individual files have already been verified by +the pre-write compile gate (see Important Constraints). This final +check is a full-package verification: ```bash go build ./path/to/package/... @@ -272,6 +276,14 @@ added, compilation status, test pass/fail. guess at the function signature - ALWAYS read existing tests before adding assertions — do not duplicate existing coverage -- ALWAYS verify generated code compiles before reporting success +- Before any Write or Edit tool call that modifies a Go source + or test file, MUST run compile verification: + 1. Run via bash: `go build ./path/to/package/...` (scoped to + the target package being modified) + 2. If the command exits with non-zero code, MUST NOT proceed + with the Write or Edit call. Report the compilation error + and continue to the next target. + 3. Only proceed with the Write or Edit call after a successful + (exit code 0) compile check. - When adding to an existing file, preserve all existing content — append only, never delete or modify existing tests diff --git a/.opencode/agents/reviewer-testing.md b/.opencode/agents/reviewer-testing.md new file mode 100644 index 0000000..d4d2766 --- /dev/null +++ b/.opencode/agents/reviewer-testing.md @@ -0,0 +1,170 @@ +--- +description: Test quality and testability auditor ensuring gaze code and specs meet coverage, isolation, and assertion standards. +mode: subagent +model: google-vertex-anthropic/claude-sonnet-4-6@default +temperature: 0.1 +tools: + write: false + edit: false + bash: false +--- + + +# Role: The Tester + +You are a test quality and testability auditor for the gaze project — a Go static analysis tool that detects observable side effects in functions, computes CRAP (Change Risk Anti-Patterns) scores by combining cyclomatic complexity with test coverage, and assesses test quality through contract coverage analysis. + +Your job is to find where tests are shallow, brittle, or missing; where coverage strategy is absent or inadequate; and where acceptance criteria are too vague to verify. You enforce Constitution Principle IV (Testability) and the project's testing conventions. + +**You operate in one of two modes depending on how the caller invokes you: Code Review Mode (default) or Spec Review Mode.** The caller will tell you which mode to use. + +--- + +## Source Documents + +Before reviewing, read: + +1. `AGENTS.md` — Testing Conventions, Coding Conventions, Build & Test Commands +2. `.specify/memory/constitution.md` — Core Principles (especially Principle IV: Testability) +3. The relevant spec, plan, and tasks files under `specs/` for the current work + +--- + +## Code Review Mode + +This is the default mode. Use this when the caller asks you to review code changes. + +### Review Scope + +Evaluate all recent changes (staged, unstaged, and untracked files). Use `git diff` and `git status` to identify what has changed. Focus on test files (`*_test.go`) and the production code they exercise. + +### Audit Checklist + +#### 1. Test Architecture + +- Are tests table-driven where multiple inputs/outputs are being exercised? +- Are test fixtures self-contained in `testdata/src/` directories loaded via `go/packages`? +- Does the test use only the standard `testing` package — no testify, gomega, or external assertion libraries? +- Do test names follow `TestXxx_Description` convention (e.g., `TestReturns_PureFunction`, `TestFormula_ZeroCoverage`)? +- Are test files alongside source in the same directory? Both internal and external package test styles are acceptable. +- Are benchmarks in separate `bench_test.go` files with `BenchmarkXxx` functions? + +#### 2. Coverage Strategy + +- Do tests cover the contract surface (returns, mutations, side effects), not just happy-path line coverage? +- Are observable side effects of the function under test verified — return values, state mutations, I/O operations? +- Is the coverage strategy appropriate for the code's risk level? High-complexity functions (CRAP > 30) need deeper coverage than simple accessors. +- Are acceptance tests named after spec success criteria (e.g., `TestSC001_ComprehensiveDetection`)? + +#### 3. Assertion Depth + +- Do assertions verify specific expected values, not just "no error"? +- Are return values, struct fields, and slice contents checked — not just length or nil/non-nil? +- Are error messages validated when error behavior is part of the contract? +- Do tests use `t.Errorf` / `t.Fatalf` directly — no assertion helpers from third-party packages? + +#### 4. Test Isolation + +- Is there shared mutable state between test cases (package-level variables modified by tests)? +- Do tests depend on execution order? Could they pass individually but fail when run together or in a different order? +- Do tests access external network resources or filesystem state outside the repo? +- Are there tests that depend on timing, wall-clock time, or sleep-based synchronization? + +#### 5. Regression Protection + +- Do tests lock down the behavior that the spec defines as critical? +- Are known-good and known-bad assertion scenarios covered by automated regression tests? +- When a bug was fixed, was a regression test added that would catch the same bug if reintroduced? +- Do JSON schema validation tests exist for JSON output contracts? + +#### 6. Convention Compliance + +- Are tests run with `-race -count=1` compatibility? Are there data races under the race detector? +- Do slow tests (spawning `go test` subprocesses, analyzing the entire module) use `testing.Short()` guards? +- Is output width verified to fit within 80-column terminals where applicable? +- Are test files and source files properly separated — no test code in production files? + +--- + +## Spec Review Mode + +Use this mode when the caller instructs you to review SpecKit artifacts instead of code. + +### Review Scope + +Read **all files** under `specs/` recursively (every feature directory and every artifact: `spec.md`, `plan.md`, `tasks.md`, `data-model.md`, `research.md`, `quickstart.md`, and `checklists/`). Also read `.specify/memory/constitution.md` and `AGENTS.md` for constraint context. + +Do NOT use `git diff` or review code files. Your scope is exclusively the specification artifacts. + +### Audit Checklist + +#### 1. Testability of Requirements + +- Can every acceptance criterion be objectively verified? Flag vague language like "works correctly", "handles gracefully", "is fast", or "is robust" without measurable definition. +- Are acceptance scenarios written in Given/When/Then format with specific, verifiable outcomes? +- Could a developer write failing tests from the spec alone, before any implementation exists? +- Are success criteria technology-agnostic and measurable (specific metrics, counts, percentages)? + +#### 2. Test Strategy Coverage + +- Does the plan define which tests are unit, integration, and e2e? +- Are test file locations and naming patterns specified or inferable from the plan? +- Is the test-to-requirement traceability clear — can you map every task tagged with test work back to a specific requirement? +- Is the TDD approach specified where appropriate (test tasks before implementation tasks)? + +#### 3. Fixture Feasibility + +- Are test fixtures implied by the plan realistic and implementable? +- If `testdata/src/` packages are needed, are they described or do they already exist? +- Are fixture dependencies documented (e.g., Go packages to load, coverage profiles to generate)? +- Could the described fixtures be created without external services or network access? + +#### 4. Coverage Expectations + +- Are coverage ratchet targets specified for new code? +- Are CRAP score thresholds defined or referenced from existing project standards? +- Is there a definition of "sufficient coverage" for this feature — not just "write tests" but measurable criteria? +- Are contract coverage expectations defined (percentage of observable side effects that must be asserted)? + +#### 5. Contract Surface Definition + +- Are the observable side effects of new functions specified clearly enough to write contract tests? +- For each new function or method: are return values, state mutations, and I/O operations documented? +- Could you enumerate the assertion mapping targets from the spec alone? +- Are error conditions and their expected behaviors defined precisely? + +#### 6. Constitution Alignment + +- Does the plan comply with Principle IV: Testability — are functions testable in isolation? +- Does the coverage strategy satisfy Principle IV's MUST requirements (coverage strategy in plan, ratchet enforcement)? +- Is missing coverage strategy flagged as CRITICAL in the spec or plan? (It should be.) +- Are the other three principles (Accuracy, Minimal Assumptions, Actionable Output) also addressed? + +--- + +## Output Format + +For each finding, provide: + +``` +### [SEVERITY] Finding Title + +**File**: `path/to/file:line` (or `specs/NNN-feature/artifact.md` in spec review mode) +**Constraint**: Which test quality dimension is violated +**Description**: What the issue is and why it matters +**Recommendation**: How to fix it +``` + +Severity levels: + +- **CRITICAL**: Missing coverage strategy, untestable requirements, constitution Principle IV violation +- **HIGH**: Vague acceptance criteria, shallow assertions (err == nil only), missing regression tests +- **MEDIUM**: Missing fixture specification, test isolation concerns, convention deviations +- **LOW**: Minor naming convention issues, style improvements, documentation gaps in tests + +## Decision Criteria + +- **APPROVE** only if tests are well-structured, coverage strategy is sound, assertions are deep, tests are isolated, and conventions are followed. +- **REQUEST CHANGES** if you find any test quality issue of MEDIUM severity or above. + +End your review with a clear **APPROVE** or **REQUEST CHANGES** verdict and a summary of findings. diff --git a/.opencode/commands/dewey-compile.md b/.opencode/commands/dewey-compile.md new file mode 100644 index 0000000..056085f --- /dev/null +++ b/.opencode/commands/dewey-compile.md @@ -0,0 +1,26 @@ +--- +description: Synthesize stored learnings into compiled knowledge articles. +--- + +# Command: /dewey-compile + +## Description + +Synthesize stored learnings into compiled knowledge articles. +Groups learnings by topic, resolves contradictions temporally, +and produces current-state articles with history. + +## Usage + +``` +/dewey-compile +``` + + +## Instructions + +Call the Dewey MCP tool `compile` to synthesize stored learnings. + +Display the returned summary showing topics compiled, articles +generated, and elapsed time. + diff --git a/.opencode/commands/dewey-curate.md b/.opencode/commands/dewey-curate.md new file mode 100644 index 0000000..06bab8b --- /dev/null +++ b/.opencode/commands/dewey-curate.md @@ -0,0 +1,27 @@ +--- +description: Curate knowledge from indexed sources into structured knowledge stores. +--- + +# Command: /dewey-curate + +## Description + +Run the Dewey curation pipeline to extract decisions, facts, patterns, +and context from indexed sources. Uses LLM analysis to produce structured +knowledge files with quality flags and confidence scores. + +## Usage + +``` +/dewey-curate +/dewey-curate --store team-decisions +/dewey-curate --force +``` + + +## Instructions + +1. Call the `curate` MCP tool +2. If the tool returns extraction prompts (no local LLM), perform synthesis +3. Report the results: files created, quality flags, confidence distribution + diff --git a/.opencode/commands/dewey-lint.md b/.opencode/commands/dewey-lint.md new file mode 100644 index 0000000..d91edbb --- /dev/null +++ b/.opencode/commands/dewey-lint.md @@ -0,0 +1,29 @@ +--- +description: Scan the knowledge base for quality issues. +--- + +# Command: /dewey-lint + +## Description + +Scan the knowledge base for quality issues: stale decisions, +uncompiled learnings, embedding gaps, and potential contradictions. + +## Usage + +``` +/dewey-lint +/dewey-lint --fix +``` + + +## Instructions + +Call the Dewey MCP tool `lint` to scan for quality issues. + +If --fix is specified, pass fix: true to auto-repair +mechanical issues (regenerate missing embeddings). + +Display the returned report showing findings and remediation +suggestions. + diff --git a/.opencode/commands/dewey-store.md b/.opencode/commands/dewey-store.md new file mode 100644 index 0000000..696a03c --- /dev/null +++ b/.opencode/commands/dewey-store.md @@ -0,0 +1,77 @@ +--- +description: Store pasted text as a Dewey learning with intelligent tag and category suggestions. +--- + +# Command: /dewey-store + +## Description + +Store ad-hoc knowledge (Slack DMs, meeting notes, decisions, +observations) as a Dewey learning. Supports three modes: +fully specified, suggested (agent analyzes text and proposes +tag/category), and extract (breaks a long conversation into +multiple learnings). + +## Usage + +``` +/dewey-store --tag auth-design --category decision +Sarah confirmed we need OAuth2 + SAML for enterprise. + +/dewey-store +Just talked to the team — we're switching to PostgreSQL. + +/dewey-store --extract +[paste a long Slack conversation or meeting transcript] +``` + + +## Instructions + +### 1. Parse Input + +Read the user's message after `/dewey-store`. + +**Check for flags**: +- `--tag `: Topic tag for the learning +- `--category `: One of decision, pattern, gotcha, context, reference +- `--extract`: Enable multi-learning extraction mode + +Everything after the flags is the **text to store**. + +If no text is provided, ask: +> "What knowledge would you like to store? Paste the text." + +### 2. Determine Mode + +**Mode A: Fully Specified** (both --tag and --category provided) +Call store_learning immediately. Skip to Step 5. + +**Mode B: Suggested** (no --tag or no --category) +Proceed to Step 3. + +**Mode C: Extract** (--extract flag present) +Proceed to Step 4. + +### 3. Analyze and Suggest (Mode B) + +**Tag suggestion**: Suggest 2-3 tags ranked by specificity. + +**Category suggestion**: Classify based on content: +- "decided", "agreed", "confirmed" → decision +- "watch out", "gotcha", "careful" → gotcha +- "pattern", "approach", "technique" → pattern +- URL, "see also", "reference" → reference +- Default → context + +Wait for user confirmation before calling store_learning. + +### 4. Multi-Learning Extraction (Mode C) + +Identify distinct pieces of knowledge. Present as numbered +list with tag/category for each. Wait for confirmation. + +### 5. Post-Store + +Display the returned identity and suggest /dewey-compile. + diff --git a/.opencode/commands/gaze-fix.md b/.opencode/commands/gaze-fix.md index 23c434a..e1987be 100644 --- a/.opencode/commands/gaze-fix.md +++ b/.opencode/commands/gaze-fix.md @@ -6,8 +6,9 @@ description: > Without arguments: detects active workflow and runs /speckit.implement or /opsx-apply. --- - + + # Command: /gaze fix ## Description @@ -183,3 +184,4 @@ Files modified: - If a generated test fails: report the failure, suggest the assertion may need adjustment, keep the test (failing tests are still valuable as documentation of expected behavior) + diff --git a/.opencode/commands/gaze.md b/.opencode/commands/gaze.md index 0aee6d1..bbccd48 100644 --- a/.opencode/commands/gaze.md +++ b/.opencode/commands/gaze.md @@ -5,8 +5,9 @@ description: > metrics only). Delegates to the gaze-reporter agent. agent: gaze-reporter --- - + + # Command: /gaze ## Description @@ -47,3 +48,4 @@ formatting. If no arguments are provided, the agent defaults to full mode with the package pattern `./...`. + diff --git a/.opencode/commands/speckit.testreview.md b/.opencode/commands/speckit.testreview.md index 93703fc..c17a1bd 100644 --- a/.opencode/commands/speckit.testreview.md +++ b/.opencode/commands/speckit.testreview.md @@ -1,8 +1,9 @@ --- description: Perform a read-only testability analysis of spec artifacts by delegating to the reviewer-testing agent in Spec Review Mode. --- - + + ## User Input ```text @@ -132,6 +133,7 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t - **Prioritize Principle IV violations** (these are always CRITICAL) - **Missing coverage strategy is CRITICAL** — not HIGH, not MEDIUM - **Report zero issues gracefully** (emit success report with testability statistics) + ## Context diff --git a/.opencode/commands/uf.address-feedback.md b/.opencode/commands/uf.address-feedback.md index ccc1edf..e91a59f 100644 --- a/.opencode/commands/uf.address-feedback.md +++ b/.opencode/commands/uf.address-feedback.md @@ -10,6 +10,8 @@ You are a token-efficient feedback analyst. The user will provide a PR number or The command follows four sequential phases (Ingest → Assess → Triage → Execute). Phases are not independently invocable — run all four in sequence every invocation. + + > **SESSION-RESUME GUARD**: If this session has been resumed > from compressed context, or if you cannot locate the > execution checklist in the current conversation, you MUST: @@ -23,6 +25,7 @@ The command follows four sequential phases (Ingest → Assess → Triage → Exe > execution checklist are authoritative > 5. Resume from the first incomplete phase + ## Arguments - **PR number** (optional): The pull request number to address feedback for (e.g., `42`). If omitted, auto-detect the open PR for the current branch. @@ -31,6 +34,7 @@ The command follows four sequential phases (Ingest → Assess → Triage → Exe --- + ## Execution Checklist At the start of execution, render this checklist in your @@ -53,6 +57,7 @@ of progress. Replace `_N_`, `_M_`, etc. with actual counts as you progress. Mark each line `[x]` when the phase completes. + --- ## Phase 1: Ingest @@ -282,19 +287,21 @@ If the item has a GitHub suggestion block, display it clearly as an applicable c ### 3.2 Author Decision -For each item, use the **AskUserQuestion tool** with +For each item, use the **question tool** with options `["Accept", "Modify", "Reject", "Ask"]`. The author chooses exactly one: | Decision | Follow-up | Queued action | |---|---|---| | **Accept** | (none) | Code change using suggested approach | -| **Modify** | Use **AskUserQuestion tool** (open-ended, no preset options) to collect the alternative approach | Code change using author's approach | -| **Reject** | Use **AskUserQuestion tool** (open-ended, no preset options) to collect evidence-based reasoning | Reply comment with reasoning | -| **Ask** | Use **AskUserQuestion tool** (open-ended, no preset options) to collect the clarification question | Reply comment with question | +| **Modify** | Use **question tool** (open-ended, no preset options) to collect the alternative approach | Code change using author's approach | +| **Reject** | Use **question tool** (open-ended, no preset options) to collect evidence-based reasoning | Reply comment with reasoning | +| **Ask** | Use **question tool** (open-ended, no preset options) to collect the clarification question | Reply comment with question | + **No item may be skipped or deferred.** Every item MUST receive a decision before the triage phase completes. + ### 3.3 Conflicting Items When presenting items flagged with CONFLICT, present both conflicting items together. The author chooses one approach. The non-chosen reviewer receives a reply comment explaining the decision. @@ -314,7 +321,7 @@ Total: N items ``` List each item with its decision. Use the -**AskUserQuestion tool** with options `["Confirm -- +**question tool** with options `["Confirm -- proceed with execution", "Revise -- change decisions"]` before execution proceeds. @@ -399,7 +406,7 @@ git status **If branch has diverged** (another contributor pushed commits): warn the author and use the -**AskUserQuestion tool** with options `["Rebase onto +**question tool** with options `["Rebase onto remote and push", "Abort -- preserve local commits"]`. Push all commits: @@ -418,9 +425,10 @@ git push origin After push succeeds (or if there are no code changes), post reply comments to the PR. Before posting, use the -**AskUserQuestion tool** with options `["Yes -- post +**question tool** with options `["Yes -- post reply comments", "No -- skip posting"]`. + **Checklist gate**: Before presenting comments for posting, verify the execution checklist shows: 1. Phase 3 is marked `[x]` with all items decided @@ -431,6 +439,7 @@ as not complete, you MUST re-read this command template and rebuild state from `state.json` and the git log. Do NOT post comments without verified checklist state. + For each item, compose the reply: | Decision | Reply content | @@ -478,7 +487,7 @@ After posting reply comments for accepted items, offer to resolve those threads: gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: ""}) { thread { isResolved } } }' ``` -Use the **AskUserQuestion tool** with options +Use the **question tool** with options `["Yes -- resolve accepted threads", "No -- leave threads open"]` before resolving. @@ -546,6 +555,7 @@ Fields `file`, `line`, `decision_reasoning`, and `commit_sha` may be `null` (gen --- + ## Guardrails 1. **No auto-merge**: This command addresses feedback. It NEVER merges the PR, approves the PR, or dismisses reviews. @@ -567,3 +577,6 @@ Fields `file`, `line`, `decision_reasoning`, and `commit_sha` may be `null` (gen 9. **File permissions**: Cache files `600`, cache directories `700`. The `.uf/feedback/` directory MUST be in `.gitignore`. 10. **Commit scope**: Only commit files directly related to addressing the specific feedback item. Do not bundle unrelated changes into feedback fix commits. + + + diff --git a/.opencode/commands/uf.agent-brief.md b/.opencode/commands/uf.agent-brief.md index 458ba8a..44aa70f 100644 --- a/.opencode/commands/uf.agent-brief.md +++ b/.opencode/commands/uf.agent-brief.md @@ -3,8 +3,7 @@ description: > Create, validate, and improve AGENTS.md -- the project briefing for AI coding agents. Auto-detects mode: creates from scratch when no AGENTS.md exists, audits and suggests improvements when - one is present. Also ensures cross-tool bridge files (CLAUDE.md, - .cursorrules) are properly configured. + one is present. --- @@ -315,7 +314,7 @@ by the Scribe and `update-agent-context.sh`. suggest changes first." 3. On confirmation, write the file to `AGENTS.md` at repo root. 4. If CHANGELOG.md was created, mention it in the summary. -5. Proceed to Step 5 (Bridge Files). +5. Proceed to Step 5 (Summary Report). ### Step 4: Audit Mode @@ -437,8 +436,7 @@ Structure sections, or "No staleness detected."] | Conditional sections | N/N | ✅/⚠ | | Build code blocks | N | ✅/⚠ | | Governance rules | N/8 | ✅/⚠ | -| Bridge: CLAUDE.md | present/missing | ✅/⚠ | -| Bridge: .cursorrules | present/missing | ✅/⚠ | + ### Improvement Suggestions @@ -458,39 +456,7 @@ If improvements were suggested: - Do NOT modify existing project-specific sections 3. After applying, re-run the audit to show updated score. -### Step 5: Bridge File Verification - -After creating or improving AGENTS.md, verify cross-tool bridge -files exist. Bridge file creation is owned by `uf init` -(`ensureCLAUDEmd()` and `ensureCursorrules()`). This command -only checks their status and suggests running `uf init` if -they are missing or misconfigured. - -**CLAUDE.md**: -1. Check if CLAUDE.md exists at repo root. -2. If it exists, check if it contains `@AGENTS.md`. -3. If missing or lacking the import: - - Report: `"⚠ CLAUDE.md: missing or does not import AGENTS.md"` - - Suggest: `"Run: uf init to create bridge files"` -4. If already configured: - - Report: `"⊘ CLAUDE.md: already imports AGENTS.md"` - -**.cursorrules**: -1. Check if .cursorrules exists at repo root. -2. If it exists, check if it references AGENTS.md. -3. If missing or lacking the reference: - - Report: `"⚠ .cursorrules: missing or does not reference AGENTS.md"` - - Suggest: `"Run: uf init to create bridge files"` -4. If already configured: - - Report: `"⊘ .cursorrules: already references AGENTS.md"` - -**Note**: `uf init` is the canonical owner of bridge file -creation. It generates CLAUDE.md with `@AGENTS.md` plus -convention pack `@` imports, and .cursorrules with AGENTS.md -reading instructions. Do NOT create bridge files with a -different marker -- defer to `uf init`. - -### Step 6: Summary Report +### Step 5: Summary Report Display a final summary: @@ -501,7 +467,6 @@ Display a final summary: ### Created ✅ AGENTS.md: generated (N lines) ✅ CHANGELOG.md: created (if newly created) - [bridge file statuses] ### Next Steps Review the Architecture section and add project-specific @@ -522,9 +487,8 @@ Display a final summary: ## Guardrails -- **NEVER modify files outside AGENTS.md, CLAUDE.md, - .cursorrules, and CHANGELOG.md** -- this command manages - agent context files only. +- **NEVER modify files outside AGENTS.md and CHANGELOG.md** + -- this command manages agent context files only. - **NEVER modify CHANGELOG.md content beyond initial creation** -- only create the file with a `# Changelog` heading if it does not exist. Do not add, edit, or remove diff --git a/.opencode/commands/uf.cobalt-crush.md b/.opencode/commands/uf.cobalt-crush.md index e7f4e4a..41e1a5f 100644 --- a/.opencode/commands/uf.cobalt-crush.md +++ b/.opencode/commands/uf.cobalt-crush.md @@ -5,7 +5,7 @@ description: > arguments: detects active workflow and runs /speckit.implement or /opsx-apply. --- - + # Command: /uf.cobalt-crush diff --git a/.opencode/commands/uf.constitution-check.md b/.opencode/commands/uf.constitution-check.md index d72cd38..3986576 100644 --- a/.opencode/commands/uf.constitution-check.md +++ b/.opencode/commands/uf.constitution-check.md @@ -2,7 +2,7 @@ description: "Check a hero constitution's alignment with the Unbound Force org constitution" agent: constitution-check --- - + # Command: /uf.constitution-check diff --git a/.opencode/commands/uf.finale.md b/.opencode/commands/uf.finale.md index 606e103..66a0604 100644 --- a/.opencode/commands/uf.finale.md +++ b/.opencode/commands/uf.finale.md @@ -33,13 +33,15 @@ stays open for human review. Works with both Speckit ## Instructions + + **Session-resume guard**: If this session has been resumed from compressed context, or if you cannot verify that the human explicitly confirmed a gate in the current uncompressed conversation history, you MUST re-read this entire template, recover state from the execution checklist below, and re-confirm any - pending gates via the **AskUserQuestion tool** before + pending gates via the **question tool** before proceeding. Do NOT rely on gate confirmations recorded in compressed context. Do NOT infer step completion from compressed summaries. When in doubt, re-confirm @@ -124,7 +126,7 @@ Run `git status --short` to inspect the working tree. > Proceed with staging all files? These files will be > included in the commit." - Use the **AskUserQuestion tool** with options + Use the **question tool** with options `["Yes -- stage all files and continue", "No -- stop here"]`. - If the user selects **"Yes -- stage all files and @@ -234,7 +236,7 @@ git status in the local branch): warn the user about the divergence before presenting the confirmation gate. -Use the **AskUserQuestion tool** with options +Use the **question tool** with options `["Push to remote", "Abort -- keep commits local"]`. - If the user selects **"Push to remote"**: @@ -397,7 +399,7 @@ gh pr view --json number,url 2>/dev/null > > ``` - Use the **AskUserQuestion tool** with options + Use the **question tool** with options `["Approve — create PR", "Edit title or body", "Provide my own title and body", "Abort — do not create PR"]`. @@ -465,7 +467,7 @@ gh pr checks --watch > 2. Re-run the checks > 3. Stop here and fix manually" - Use the **AskUserQuestion tool** to ask the user how + Use the **question tool** to ask the user how to proceed. >>> END MANDATORY GATE <<< @@ -543,7 +545,7 @@ conflict to the user and present recovery options: > 5. Spawn sub-agent to resolve conflicts > (AI-assisted)" -Use the **AskUserQuestion tool** to ask the user +Use the **question tool** to ask the user which option to take. After the user selects an option, update the execution checklist: set `CONFLICT_OPTION=` (where N is the selected option @@ -969,3 +971,5 @@ the OpenSpec and Speckit workflows: - All changes are committed before any branch switch - The remote branch is NOT deleted — it stays open with the PR until a reviewer merges + + diff --git a/.opencode/commands/uf.init.md b/.opencode/commands/uf.init.md index 45c00e1..ea665bb 100644 --- a/.opencode/commands/uf.init.md +++ b/.opencode/commands/uf.init.md @@ -5,7 +5,7 @@ description: > correct insertion points. Run after uf init, uf setup, or updating the OpenSpec CLI. --- - + # Command: /uf.init @@ -546,7 +546,7 @@ step: run `.specify/scripts/bash/check-prerequisites.sh ### Step 6: Speckit Command Guardrails Inject a `## Guardrails` section into ALL 9 -`.opencode/commands/speckit.*.md` files. Use two +`.opencode/commands/speckit.*.md` files. Use four variants depending on the command type. **Spec-phase commands** (get Guardrails WITH @@ -558,29 +558,53 @@ review-rationale sentence): - `speckit.analyze.md` - `speckit.checklist.md` -**Execution/utility commands** (get Guardrails WITHOUT -review-rationale sentence): -- `speckit.implement.md` -- `speckit.constitution.md` -- `speckit.taskstoissues.md` +**`speckit.implement.md`** (command-specific: implementation +guardrails — this command writes source code) + +**`speckit.constitution.md`** (command-specific: constitution +guardrails — writes to `.specify/memory/` and templates) + +**`speckit.taskstoissues.md`** (command-specific: issue creation +guardrails — creates GitHub issues via MCP API) For each file: 1. **Read** the file content 2. **Check** if a `## Guardrails` section already exists - (search for the heading text `## Guardrails`) + (search for the heading text `## Guardrails` as a + markdown heading outside of fenced code blocks) 3. **If NOT present**: Append the appropriate guardrails variant at the very end of the file. Report `✅ : guardrails injected` -4. **If already present**: Perform a secondary check - for spec-phase commands only -- search for the phrase - "review defeats the purpose". If the Guardrails - heading exists but the review-rationale sentence is - missing, append the sentence to the existing - Guardrails section. Report - `✅ : review-rationale added`. +4. **If already present — spec-phase commands**: Perform + a secondary check — search for the phrase "review + defeats the purpose". If the Guardrails heading exists + but the review-rationale sentence is missing, append + the sentence to the existing Guardrails section. + Report `✅ : review-rationale added`. If the sentence is already present, report `⊘ : guardrails already present (skipped)` +5. **If already present — command-specific commands** + (`implement`, `constitution`, `taskstoissues`): + Check for the command's correctness marker: + + | Command | Correctness marker | + |---------|-------------------| + | `speckit.implement.md` | "writes source code" | + | `speckit.constitution.md` | ".specify/memory/" | + | `speckit.taskstoissues.md` | "GitHub issues via" | + + If the correctness marker IS present in the existing + `## Guardrails` section, the guardrails are correct. + Report + `⊘ : guardrails already present (skipped)` + + If the correctness marker is ABSENT, the guardrails + are incorrect (likely the old shared template). + Replace the entire `## Guardrails` section (from the + heading to the next `##` heading or end of file) with + the command-specific guardrail block. Report + `✅ : guardrails corrected` **Spec-phase guardrails block** (with review-rationale): @@ -604,32 +628,51 @@ For each file: defeats the purpose of the spec-first workflow. ``` -**Execution/utility guardrails block** (no -review-rationale): +**Implement guardrails block** (`speckit.implement.md`): ```markdown ## Guardrails -- **NEVER modify source code** — this command updates - spec artifacts ONLY. Implementation changes belong in - `/speckit.implement`, `/uf.unleash`, or `/uf.cobalt-crush`. -- **NEVER modify test files, Go source, Markdown agents, - convention packs, or config files** outside the - `specs/NNN-*/` feature directory. +- This command **writes source code** — implementation + is its primary purpose. It executes the tasks defined + in the active feature's `tasks.md`. +- Scope modifications to the active feature's + implementation plan. Do not make changes unrelated to + the current task group. +- Mark task checkboxes `[x]` as each task is completed. +``` + +**Constitution guardrails block** (`speckit.constitution.md`): + +```markdown + +## Guardrails + +- This command updates the project constitution and + propagates changes to dependent templates. - The ONLY files this command may write are: - - `FEATURE_SPEC` (the spec.md file) - - Files within `FEATURE_DIR` (spec artifacts: - plan.md, tasks.md, research.md, data-model.md, - quickstart.md, contracts/, checklists/) + - `.specify/memory/constitution.md` + - `.specify/templates/*-template.md` (consistency + propagation) +- Do NOT modify source code, test files, or any files + outside the `.specify/` directory. ``` -**Note**: `speckit.implement.md` is an exception — it IS -allowed to modify source code. However, the guardrails -section is still injected for consistency. The implement -command's own instructions override the guardrails where -they conflict (implement's instructions explicitly say -to write source code). +**Taskstoissues guardrails block** (`speckit.taskstoissues.md`): + +```markdown + +## Guardrails + +- This command creates **GitHub issues via** the MCP API. + It does NOT write local files. +- Issues MUST only be created in the repository matching + the current Git remote. NEVER create issues in + unrelated repositories. +- Do NOT modify source code, spec artifacts, or any + local files. +``` ### Step 7: Speckit UF Customizations @@ -742,6 +785,7 @@ After processing all customizations, display a summary: ### Legacy Directory Cleanup [status] [item]: [action] ... + ### Summary Applied: N | Already present: N | Errors: N ``` diff --git a/.opencode/commands/uf.review-council.md b/.opencode/commands/uf.review-council.md index 02ec6f3..d8487a6 100644 --- a/.opencode/commands/uf.review-council.md +++ b/.opencode/commands/uf.review-council.md @@ -4,6 +4,8 @@ description: Run the reviewer governance council to audit codebase or spec compl # Command: /uf.review-council + + > **Session-resume guard**: If this session was resumed > from compressed context, re-read this entire template > before continuing. Do NOT infer step completion from @@ -14,6 +16,8 @@ description: Run the reviewer governance council to audit codebase or spec compl > harmless; skipping steps due to stale context causes > incomplete reviews or unauthorized actions. + + > **EXECUTION CHECKLIST** — Update each item using the > Edit tool as you complete it. Mark `[x]` when done. > @@ -33,6 +37,7 @@ description: Run the reviewer governance council to audit codebase or spec compl > - [ ] Step 7f: Human confirmation (MANDATORY GATE) > - [ ] Step 7g: Post review + ## User Input ```text @@ -295,6 +300,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A 2. Delegate the review to all **discovered** reviewer agents in parallel using the Task tool. For each discovered agent, use the focus area from the Known Reviewer Roles reference table to provide targeted context. For any discovered agent not in the table, use a generic prompt: "Review the current changes for quality, correctness, and compliance. Return your verdict (APPROVE or REQUEST CHANGES) along with all findings." + **CRITICAL — Review Scope Rule**: The review scope is ALWAYS the **full branch diff** (`git diff main...HEAD`), meaning ALL files changed on the branch relative to @@ -307,6 +313,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A produces incomplete reviews that miss findings in earlier commits on the branch. + **Review context enrichment**: Append the following context sections to each Divisor agent's review prompt: @@ -490,13 +497,13 @@ Review the current codebase for compliance with the Behavioral Constraints in `A - If a prior review with the **same verdict** exists: Inform the user that a prior review exists and the latest review takes precedence. Use the - **AskUserQuestion tool** with options + **question tool** with options `["Yes -- post new review", "No -- skip posting"]`. - If a prior review with a **different verdict** exists: Inform the user of the prior verdict and that the new review will override it. Use the - **AskUserQuestion tool** with options + **question tool** with options `["Yes -- override with ", "No -- keep existing "]`. @@ -655,6 +662,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A **Checkpoint**: Mark `Step 7e` complete in the EXECUTION CHECKLIST using the Edit tool before proceeding. + #### Step 7f -- Verdict Mapping and Human Confirmation >>> MANDATORY GATE: HUMAN CONFIRMATION REQUIRED <<< @@ -665,7 +673,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A current uncompressed conversation history, you MUST re-present the review content (verdict + all comments) and obtain fresh confirmation via the - **AskUserQuestion tool** before posting. Do NOT rely + **question tool** before posting. Do NOT rely on confirmation recorded in compressed context. When in doubt, re-confirm — false re-confirmation is harmless; posting without consent is a violation. @@ -681,7 +689,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A | APPROVE WITH ADVISORIES | `COMMENT` | Display the verdict context, then use the - **AskUserQuestion tool** for confirmation: + **question tool** for confirmation: For APPROVE verdicts: > "This will post an APPROVE review, which may unblock @@ -709,7 +717,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A COMMENT). **CRITICAL RULE**: NEVER post reviews without explicit - human confirmation via the **AskUserQuestion tool**. + human confirmation via the **question tool**. Always show the exact content (verdict type + all comments) that will be posted and wait for the user to select a confirming option. Mark `Step 7f` as @@ -718,6 +726,7 @@ Review the current codebase for compliance with the Behavioral Constraints in `A >>> END MANDATORY GATE <<< + #### Step 7g -- Post Review Construct a JSON payload containing: @@ -868,8 +877,12 @@ step, determine which artifacts to review: --- + ## Verdict The council returns **APPROVE** only when all discovered reviewers return **APPROVE**. Any single **REQUEST CHANGES** from a discovered reviewer means the council verdict is **REQUEST CHANGES**. Absent reviewers (known roles whose agent files were not found during discovery) do not affect the verdict but are noted in the discovery summary. In Spec Review Mode, the council may return **APPROVE WITH ADVISORIES** when all LOW/MEDIUM findings have been auto-fixed but HIGH/CRITICAL findings remain that require human judgment. The advisories are the outstanding HIGH/CRITICAL findings. The discovery summary is included regardless of the verdict. + + + diff --git a/.opencode/commands/uf.review-pr.md b/.opencode/commands/uf.review-pr.md index 955a25c..2658e41 100644 --- a/.opencode/commands/uf.review-pr.md +++ b/.opencode/commands/uf.review-pr.md @@ -7,6 +7,8 @@ description: "Review PR #$ARGUMENTS — alignment, security, and constitution co You are a token-efficient code reviewer. The user will provide a PR number or you will auto-detect it from the current branch. Delegate deterministic checks to local tools and CI results first, then apply AI judgment only where tools cannot reach: intent alignment, security patterns, and architectural concerns. + + ## Arguments - **PR number** (optional): The pull request number to review (e.g., `42`). If omitted, the command auto-detects the open PR for the current branch. @@ -67,6 +69,7 @@ foundation of the review — without them, AI-only findings lack verification and the review does not meet the command's quality standard. + ### 1. Resolve PR Number **If `PR_NUMBER` was already set from the argument**: skip @@ -109,7 +112,7 @@ Categorize each check as: - **SKIPPED**: Check was skipped If checks are still PENDING, inform the user and use -the **AskUserQuestion tool** with options +the **question tool** with options `["Wait for checks to complete", "Proceed with available results"]`. @@ -156,11 +159,11 @@ from Step 2 metadata: **If total diff lines > 2000 OR changed files > 50**: -Use the **AskUserQuestion tool** with options +Use the **question tool** with options `["Review all files", "Focus on specific files"]`. If the user selects "Focus on specific files", follow up -with the **AskUserQuestion tool** (open-ended, no preset +with the **question tool** (open-ended, no preset options) to ask which files or directories to focus on. Record the user's choice as `FILE_FOCUS_SCOPE`: @@ -431,6 +434,7 @@ When the combined comment text exceeds this limit: 4. Truncate the remainder with a note: "N additional prior comments truncated for token budget" + ###### Step E.5. Error Handling If any `gh api` call in this step returns 403, 404, or @@ -466,6 +470,7 @@ analysis. For each finding: have additional context or a different severity assessment. Annotate, don't hide. + **Path-based review focus and walkthrough**: Use the file classifications and walkthrough summaries from Step C (review-context skill, Protocols 3 and 4). @@ -759,7 +764,7 @@ I identified pre-existing CI failure(s) that are NOT caused by this PR: These failures also occur on the base branch (). ``` -Use the **AskUserQuestion tool** with options +Use the **question tool** with options `["Yes -- create fix branch", "No -- skip"]`. **If the user selects "Yes -- create fix branch"**: @@ -874,7 +879,7 @@ Verdict: Regardless of finding severities, always offer to post the review as a formal GitHub review on the PR. Use the -**AskUserQuestion tool** with options +**question tool** with options `["Yes -- post as GitHub review", "No -- terminal summary is sufficient"]`. @@ -894,13 +899,13 @@ review fetch): - If a prior review with the **same verdict** exists: Inform the user that a prior review exists and the latest review takes precedence. Use the - **AskUserQuestion tool** with options + **question tool** with options `["Yes -- post new review", "No -- skip posting"]`. - If a prior review with a **different verdict** exists: Inform the user of the prior verdict and that the new review will override it. Use the - **AskUserQuestion tool** with options + **question tool** with options `["Yes -- override with ", "No -- keep existing "]`. @@ -977,11 +982,12 @@ account is not listed in CODEOWNERS. in the current uncompressed conversation history, you MUST re-present the review content (verdict + all comments) and obtain fresh confirmation via the - **AskUserQuestion tool** before posting. Do NOT rely + **question tool** before posting. Do NOT rely on confirmation recorded in compressed context. When in doubt, re-confirm — false re-confirmation is harmless; posting without consent is a violation. + 1. **Prepare comments**: For each finding that maps to a specific file and line range in the diff, prepare an in-line comment with: @@ -1033,18 +1039,18 @@ account is not listed in CODEOWNERS. - COMMENT → `"event": "COMMENT"` Display the verdict context, then use the - **AskUserQuestion tool** for confirmation: + **question tool** for confirmation: For APPROVE verdicts: inform the user that this may unblock merge in repos with branch protection and that the review will be labeled as AI-generated. - Use the **AskUserQuestion tool** with options + Use the **question tool** with options `["Approve -- post review", "No -- skip posting", "Edit comments first", "Change verdict"]`. For REQUEST CHANGES or COMMENT verdicts: inform the user that this will block merge in repos with branch - protection. Use the **AskUserQuestion tool** with + protection. Use the **question tool** with options `["Yes -- post review", "No -- skip posting", "Edit comments first", "Change verdict"]`. @@ -1085,10 +1091,10 @@ account is not listed in CODEOWNERS. suggest re-authenticating with `gh auth login`. - **"No -- skip posting"**: Skip posting, the terminal summary is sufficient - - **"Edit comments first"**: Let the user modify comments before posting, then re-confirm with the **AskUserQuestion tool** + - **"Edit comments first"**: Let the user modify comments before posting, then re-confirm with the **question tool** 5. **CRITICAL RULE**: NEVER post reviews without explicit - human confirmation via the **AskUserQuestion tool**. + human confirmation via the **question tool**. Always show the exact content (verdict type + all comments) that will be posted and wait for the user to select a confirming option. For APPROVE verdicts, @@ -1097,3 +1103,6 @@ account is not listed in CODEOWNERS. merge-unblocking consequence. >>> END MANDATORY GATE <<< + + + diff --git a/.opencode/commands/uf.triage-issue.md b/.opencode/commands/uf.triage-issue.md index 0dfcde1..91c44d6 100644 --- a/.opencode/commands/uf.triage-issue.md +++ b/.opencode/commands/uf.triage-issue.md @@ -10,6 +10,8 @@ You are a token-efficient issue analyst. The user provides a GitHub issue number The command follows four sequential phases (Ingest → Assess → Classify → Act). Phases are not independently invocable — run all four in sequence every invocation. + + ## Arguments - **Issue number** (required): The GitHub issue number to triage (e.g., `42`). @@ -240,7 +242,7 @@ Split: <"recommended" with count, or "not recommended"> ### 4.2 Label Application -**All label mutations require user confirmation.** Before creating or applying any label, use the **AskUserQuestion tool** to obtain explicit confirmation. The `duplicate` label has an additional supplementary confirmation gate because it carries implicit "close" semantics. +**All label mutations require user confirmation.** Before creating or applying any label, use the **question tool** to obtain explicit confirmation. The `duplicate` label has an additional supplementary confirmation gate because it carries implicit "close" semantics. **Label mapping**: @@ -260,7 +262,7 @@ Split: <"recommended" with count, or "not recommended"> **Path A — Label does NOT exist in the repository**: -Inform the user: "The label ' diff --git a/.opencode/commands/uf.unleash.md b/.opencode/commands/uf.unleash.md index 81fcaa6..04f2137 100644 --- a/.opencode/commands/uf.unleash.md +++ b/.opencode/commands/uf.unleash.md @@ -7,7 +7,7 @@ description: > instructions. Exits to the human only when it genuinely needs human judgment. --- - + # Command: /uf.unleash @@ -29,6 +29,8 @@ off on re-run. ## Instructions + + > **SESSION-RESUME GUARD**: If you are resuming this > command after context compression or a session restart, > STOP and re-read this entire template before continuing. @@ -75,7 +77,8 @@ If `swarm_worktree_list` is not available (Replicator not installed), skip this step silently. > CHECKPOINT: Mark Step 0 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 1. Do NOT ask for confirmation. ### 1. Branch Safety Gate @@ -129,7 +132,8 @@ git rev-parse --abbrev-ref HEAD > `/opsx-propose` to create one." > CHECKPOINT: Mark Step 1 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 2. Do NOT ask for confirmation. ### 2. Resumability Detection @@ -192,7 +196,8 @@ skip directly to step 7 (retrospective) since it is idempotent. > CHECKPOINT: Mark Step 2 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 3. Do NOT ask for confirmation. ### 3. Step 1 -- Clarify @@ -270,7 +275,8 @@ needed" and proceed to step 2. ``` > CHECKPOINT: Mark Step 3 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 4. Do NOT ask for confirmation. ### 4. Step 2 -- Plan @@ -294,7 +300,8 @@ Generate the implementation plan by delegating to the > Check the agent output for errors." > CHECKPOINT: Mark Step 4 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 5. Do NOT ask for confirmation. ### 5. Step 3 -- Tasks @@ -317,7 +324,8 @@ Generate the task list by delegating to the > Check the agent output for errors." > CHECKPOINT: Mark Step 5 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 6. Do NOT ask for confirmation. ### 6. Step 4 -- Spec Review @@ -377,7 +385,8 @@ analysis + quality validation) in a single pass. ``` > CHECKPOINT: Mark Step 6 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 7. Do NOT ask for confirmation. ### 7. Step 5 -- Implement @@ -534,7 +543,8 @@ logic used by `/uf.review-council` and `/uf.review-pr`. ``` > CHECKPOINT: Mark Step 7 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 8. Do NOT ask for confirmation. ### 8. Step 6 -- Code Review @@ -605,7 +615,8 @@ quality data. ``` > CHECKPOINT: Mark Step 8 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 9. Do NOT ask for confirmation. ### 9. Step 7 -- Retrospective @@ -644,10 +655,18 @@ memory. lost. > CHECKPOINT: Mark Step 9 complete in the execution -> checklist before proceeding. +> checklist before proceeding. Proceed immediately to +> Step 10. Do NOT ask for confirmation. ### 10. Step 8 -- Demo +> **OUTPUT FIDELITY GUARD**: Before composing any demo +> output, re-read this Step 10 Demo section (from this +> heading through the CHECKPOINT blockquote below). +> The template is the sole authority for prescribed +> output format — NEVER reconstruct it from memory or +> compressed context summaries. + Present structured demo instructions to the developer. 1. **What Was Built**: @@ -678,11 +697,13 @@ Present structured demo instructions to the developer. 4. **Test Results**: summarize the test output from the most recent build/test checkpoint. -5. **Next Steps**: always present these options: - - `/uf.finale` to commit, push, create PR, and return - to main - - `/speckit.clarify` to refine the spec and re-run - `/uf.unleash` +5. **Next Steps**: always present exactly these two + options as shown in the format block below — do not + paraphrase, add, or remove options. + **Note**: The pre-PR `/uf.review-council` requirement + is already satisfied by Step 8 (Code Review). Do NOT + re-suggest `/uf.review-council` or hand-roll git + commit/push/PR steps in the demo output. Format the output as: @@ -715,6 +736,13 @@ Format the output as: ## Guardrails +- **NEVER pause between steps to ask for human + confirmation** -- proceed immediately from one step to + the next. The only valid reasons to exit the pipeline + are: unanswerable clarification questions, + HIGH/CRITICAL spec findings, build/test failures, + merge conflicts, and 3 review iterations exhausted. + All other transitions are autonomous. - **NEVER run on `main`** -- the command is for Speckit (`NNN-*`) and OpenSpec (`opsx/*`) feature branches - **NEVER skip spec review exit on HIGH/CRITICAL** -- @@ -738,3 +766,8 @@ Format the output as: - **NEVER hardcode build/test commands** -- load the `pre-flight` skill to derive them from `.github/workflows/` and local tool configs +- **NEVER improvise Demo exit text** -- the "Next Steps" + section in Step 10 prescribes the exact output; re-read + and reproduce it verbatim + + diff --git a/.opencode/dcp.jsonc b/.opencode/dcp.jsonc new file mode 100644 index 0000000..58af7f4 --- /dev/null +++ b/.opencode/dcp.jsonc @@ -0,0 +1,10 @@ +{ + "$schema": "https://raw.githubusercontent.com/Opencode-DCP/opencode-dynamic-context-pruning/master/dcp.schema.json", + // Enable tag preservation during DCP compression. + // Slash command files in .opencode/commands/ use tags + // to mark execution-critical sections (guardrails, checklists, + // mandatory gates) that must survive context pruning. + "compress": { + "protectTags": true + } +} diff --git a/.opencode/references/doc-scoring-model.md b/.opencode/references/doc-scoring-model.md index 4c8c672..44f7728 100644 --- a/.opencode/references/doc-scoring-model.md +++ b/.opencode/references/doc-scoring-model.md @@ -43,4 +43,4 @@ After recalculation, re-derive labels from updated confidence scores: | ≥ 80 | contractual | | 50–79 | ambiguous | | < 50 | incidental | - + diff --git a/.opencode/references/example-report.md b/.opencode/references/example-report.md index b7cbf14..9ea3c7a 100644 --- a/.opencode/references/example-report.md +++ b/.opencode/references/example-report.md @@ -70,4 +70,4 @@ Top 5 Prioritized Recommendations 4. 🟡 Resolve ambiguous classifications — 66.5% ambiguous rate can be reduced with project documentation providing stronger signal evidence. 5. 🟢 Run per-package quality analysis — module-level returned 0 tests; per-package analysis provides granular contract coverage data. ``` - + diff --git a/.opencode/skills/always-on-guidance/SKILL.md b/.opencode/skills/always-on-guidance/SKILL.md index 3a9ebe6..e8e60b6 100644 --- a/.opencode/skills/always-on-guidance/SKILL.md +++ b/.opencode/skills/always-on-guidance/SKILL.md @@ -3,6 +3,7 @@ name: always-on-guidance description: Global coding rules and tool usage discipline tags: [always-on, coding, quality] --- + # Always-On Guidance @@ -14,12 +15,12 @@ Rules that apply to every coding session. ## Tool Usage Discipline -- Check `hivemind_find` before solving problems from scratch +- Check `hivemind_find` / `dewey_semantic_search` before solving problems from scratch - Read files before editing — never guess at content -- Use `org_*` tools for work item management -- Use `comms_*` tools for agent messaging and file reservations -- Use `forge_*` tools for multi-agent coordination -- Use `hivemind_*` tools for learning storage and retrieval +- Use `replicator_org_*` tools for work item management +- Use `replicator_comms_*` tools for agent messaging and file reservations +- Use `replicator_forge_*` tools for multi-agent coordination +- Use `dewey_store_learning` / `dewey_semantic_search` for learning storage and retrieval ## Code Quality @@ -53,7 +54,18 @@ Rules that apply to every coding session. - Handle all error paths — no ignored returns - Use `errors.Is` for sentinel error checks +## Command Template Fidelity + +- When a command template prescribes a fixed exit or + output format, re-read that section from the template + file before emitting — especially after context + compression +- After compression, the template file is the sole + authority for prescribed output format — never + reconstruct it from memory or compressed summaries + ## Git Discipline - Conventional commits: `type: description` +- NEVER force push to main - Commit early, commit often diff --git a/.opencode/skills/speckit-workflow/SKILL.md b/.opencode/skills/speckit-workflow/SKILL.md index 09ffdf6..8855421 100644 --- a/.opencode/skills/speckit-workflow/SKILL.md +++ b/.opencode/skills/speckit-workflow/SKILL.md @@ -6,7 +6,7 @@ tags: - workflow - decomposition --- - + # Speckit Workflow — Swarm Skill @@ -37,7 +37,7 @@ current feature branch before any branch switch occurs. `main`. - Before creating a new feature branch (via `/speckit.specify`), check `git status --short` for uncommitted changes. If - uncommitted changes exist, use the **AskUserQuestion tool** + uncommitted changes exist, use the **question tool** to confirm before proceeding. Include the `git status --short` output in the question so the user can see which files are uncommitted: diff --git a/.opencode/uf/packs/content.md b/.opencode/uf/packs/content.md index 974d857..72b1a5d 100644 --- a/.opencode/uf/packs/content.md +++ b/.opencode/uf/packs/content.md @@ -3,7 +3,7 @@ pack_id: content language: Any version: 1.0.0 --- - + # Convention Pack: Content (Documentation, Blog, PR/Comms) diff --git a/.opencode/uf/packs/default.md b/.opencode/uf/packs/default.md index baa47f3..513117f 100644 --- a/.opencode/uf/packs/default.md +++ b/.opencode/uf/packs/default.md @@ -3,7 +3,7 @@ pack_id: default language: Any version: 1.0.0 --- - + # Convention Pack: Default (Language-Agnostic) diff --git a/.opencode/uf/packs/go.md b/.opencode/uf/packs/go.md index 8054d52..605af52 100644 --- a/.opencode/uf/packs/go.md +++ b/.opencode/uf/packs/go.md @@ -3,7 +3,7 @@ pack_id: go language: Go version: 1.0.0 --- - + # Convention Pack: Go diff --git a/.opencode/uf/packs/severity.md b/.opencode/uf/packs/severity.md index 1874bf0..31b5f65 100644 --- a/.opencode/uf/packs/severity.md +++ b/.opencode/uf/packs/severity.md @@ -1,7 +1,7 @@ --- description: "Shared severity level definitions for all Divisor Council personas." --- - + # Severity Convention Pack diff --git a/.opencode/uf/packs/typescript.md b/.opencode/uf/packs/typescript.md index a656281..9b1eb42 100644 --- a/.opencode/uf/packs/typescript.md +++ b/.opencode/uf/packs/typescript.md @@ -3,7 +3,7 @@ pack_id: typescript language: TypeScript version: 1.0.0 --- - + # Convention Pack: TypeScript diff --git a/internal/agentkit/content/skills/always-on-guidance/SKILL.md b/internal/agentkit/content/skills/always-on-guidance/SKILL.md index 3a9ebe6..e8e60b6 100644 --- a/internal/agentkit/content/skills/always-on-guidance/SKILL.md +++ b/internal/agentkit/content/skills/always-on-guidance/SKILL.md @@ -3,6 +3,7 @@ name: always-on-guidance description: Global coding rules and tool usage discipline tags: [always-on, coding, quality] --- + # Always-On Guidance @@ -14,12 +15,12 @@ Rules that apply to every coding session. ## Tool Usage Discipline -- Check `hivemind_find` before solving problems from scratch +- Check `hivemind_find` / `dewey_semantic_search` before solving problems from scratch - Read files before editing — never guess at content -- Use `org_*` tools for work item management -- Use `comms_*` tools for agent messaging and file reservations -- Use `forge_*` tools for multi-agent coordination -- Use `hivemind_*` tools for learning storage and retrieval +- Use `replicator_org_*` tools for work item management +- Use `replicator_comms_*` tools for agent messaging and file reservations +- Use `replicator_forge_*` tools for multi-agent coordination +- Use `dewey_store_learning` / `dewey_semantic_search` for learning storage and retrieval ## Code Quality @@ -53,7 +54,18 @@ Rules that apply to every coding session. - Handle all error paths — no ignored returns - Use `errors.Is` for sentinel error checks +## Command Template Fidelity + +- When a command template prescribes a fixed exit or + output format, re-read that section from the template + file before emitting — especially after context + compression +- After compression, the template file is the sole + authority for prescribed output format — never + reconstruct it from memory or compressed summaries + ## Git Discipline - Conventional commits: `type: description` +- NEVER force push to main - Commit early, commit often diff --git a/opencode.json b/opencode.json index 9507ac1..6e57884 100644 --- a/opencode.json +++ b/opencode.json @@ -1,6 +1,5 @@ { "$schema": "https://opencode.ai/config.json", - "protectTags": true, "mcp": { "dewey": { "type": "local", diff --git a/openspec/schemas/unbound-force/schema.yaml b/openspec/schemas/unbound-force/schema.yaml index 4189c1d..9e3a612 100644 --- a/openspec/schemas/unbound-force/schema.yaml +++ b/openspec/schemas/unbound-force/schema.yaml @@ -74,4 +74,4 @@ apply: task as you complete it. Verify that the implementation maintains constitution alignment as documented in the proposal. -# scaffolded by uf v0.15.0 +# scaffolded by uf vdev diff --git a/openspec/schemas/unbound-force/templates/design.md b/openspec/schemas/unbound-force/templates/design.md index 3201686..2165de3 100644 --- a/openspec/schemas/unbound-force/templates/design.md +++ b/openspec/schemas/unbound-force/templates/design.md @@ -17,4 +17,4 @@ ## Risks / Trade-offs - + diff --git a/openspec/schemas/unbound-force/templates/proposal.md b/openspec/schemas/unbound-force/templates/proposal.md index bc1a656..45d5fa9 100644 --- a/openspec/schemas/unbound-force/templates/proposal.md +++ b/openspec/schemas/unbound-force/templates/proposal.md @@ -54,4 +54,4 @@ output? Does it maintain provenance metadata? --> - + diff --git a/openspec/schemas/unbound-force/templates/spec.md b/openspec/schemas/unbound-force/templates/spec.md index 343982c..7b1e55a 100644 --- a/openspec/schemas/unbound-force/templates/spec.md +++ b/openspec/schemas/unbound-force/templates/spec.md @@ -20,4 +20,4 @@ ### Requirement: - + diff --git a/openspec/schemas/unbound-force/templates/tasks.md b/openspec/schemas/unbound-force/templates/tasks.md index 9b1ecfb..e5bbfc7 100644 --- a/openspec/schemas/unbound-force/templates/tasks.md +++ b/openspec/schemas/unbound-force/templates/tasks.md @@ -19,4 +19,4 @@ ## 2. - [ ] 2.1 - +