claudify-agent 1.0.9 → 1.0.11

package/.claude/commands/backbone-init.md

@@ -12,6 +12,7 @@ Draft or refresh `BACKBONE.md` at the project root. Notes from me: $ARGUMENTS
    - CI workflows for the real lint/test/build commands.
 2. Fill every section of the existing `BACKBONE.md` (or the template if missing):
    - Docs index: one line per doc, with status. Mark a doc outdated only with evidence (superseded note, archive folder, version mismatch); otherwise ask.
+   - Domain glossary: the main business nouns from models/entities/DB schema/status enums, with meaning and states. Ask me when a name is cryptic (e.g. `tbl_sub_v3`, `flag_v2`) instead of guessing. Keep it to the terms that matter (~15).
    - Capabilities: one line per `spec/specs/*.md` (or `openspec/specs/*/` if migrating from OpenSpec).
    - Invariants: only rules found in docs or that I confirm. Never invent business rules.
 3. Keep it under ~80 lines. Link, never copy.

package/.claude/commands/spec-apply.md

@@ -7,8 +7,10 @@ Implement spec change: $ARGUMENTS
 
 1. Read `spec/changes/<change-name>.md`; respect the Invariants in `BACKBONE.md`. Nothing else up front; read code only as each task needs it.
 2. Take the requested task, or the first unchecked `- [ ]` task. Work one task at a time.
-3. Implement it, then run its DoD. Fix until it passes (max 5 attempts, then stop and report).
+   Business-rule guard: money amounts, limits, fees, refunds, permissions, status transitions, legal/compliance rules MUST come from an AC, the Invariants or a linked doc. If the task needs one that is not written down, stop and ask me; never pick a "reasonable" value. Add my answer to the spec before coding it.
+3. Implement it with tests for the ACs it covers. Each test name contains the full AC ID, e.g. `describe("refund/AC-2: expired QR is refunded", ...)` or `func TestRefund_AC2` with a `// refund/AC-2` comment. Use the Domain glossary terms for names. Then run its DoD. Fix until it passes (max 5 attempts, then stop and report).
 4. Tick it `- [x]` in the change file. If reality differs from the spec, update the spec (Requirements/Design) in the same step and tell me.
-5. Report in 2-3 lines: task done, proof run, next task. Continue to the next task only if I asked for more than one.
+5. If I ask you to commit: `feat(<change-name>): <what>` and list the AC IDs covered in the body.
+6. Report in 2-3 lines: task done, proof run, next task. Continue to the next task only if I asked for more than one.
 
 When every task is ticked, set `Status: done` and suggest `/spec-archive <change-name>`.

package/.claude/commands/spec-archive.md

@@ -6,8 +6,9 @@ argument-hint: <change-name>
 Archive spec change: $ARGUMENTS
 
 1. Read `spec/changes/<change-name>.md`. Refuse if any task is unchecked; list them.
+   Run `node .claude/scripts/spec-check.mjs spec/changes/<change-name>.md`. If an AC has no test, list it and ask me: add the test, or archive anyway (I accept the gap).
 2. For each `### <capability>` block under Requirements, update `spec/specs/<capability>.md` (create if new):
-   - Keep only Requirements and Scenarios: the current truth of the system, no history, no tasks.
+   - Keep only Requirements and their ACs (with IDs unchanged): the current truth of the system, no history, no tasks.
    - ADDED → append. MODIFIED → replace the requirement of the same name in full. REMOVED → delete it.
    - If a MODIFIED/REMOVED name does not exist in the backbone, stop and ask instead of guessing.
 3. Move the change file to `spec/changes/archive/YYYY-MM-DD-<change-name>.md`.

package/.claude/commands/spec-new.md

@@ -22,19 +22,22 @@ Status: draft | Depends on: <change or none>
 ### <capability> (new | modified)
 #### ADDED Requirement: <name>
 <statement with SHALL/MUST>
-- Scenario <name>: GIVEN ... WHEN ... THEN ...
+- AC-1 <name>: GIVEN ... WHEN ... THEN ...
+- AC-2 <name>: GIVEN ... WHEN ... THEN ...
 #### MODIFIED Requirement: <existing name>
-<full new text, not just the diff>
+<full new text and its ACs, not just the diff>
 #### REMOVED Requirement: <existing name>
 <reason>
 ## Design
 <only decisions not obvious from the code: data flow, schema, API, edge cases. Omit section if trivial.>
 ## Risks
 ## Tasks
-- [ ] 1. <task> — files: ... — DoD: ...
+- [ ] 1. <task> — files: ... — covers: <capability>/AC-1, AC-2 — DoD: ...
 ```
 
-4. Keep the whole file under ~800 words, plus ~300 per extra capability. No restating config, docs or code; link them.
+4. AC IDs: numbered per capability and never reused. New ACs continue after the highest `AC-<n>` in `spec/specs/<capability>.md`; a MODIFIED requirement keeps its existing AC IDs. The full ID is `<capability>/AC-<n>`.
+5. Use the terms from the Domain glossary in `BACKBONE.md`. A new domain term → add it to the glossary in the same step.
+6. Keep the whole file under ~800 words, plus ~300 per extra capability. No restating config, docs or code; link them.
    If it still does not fit (e.g. more than 4 capabilities), propose splitting into smaller changes with `Depends on:` instead of one giant spec.
-5. Add the change as one line under "Open changes" in `BACKBONE.md`.
-6. Do not write code. Finish by showing the task list and asking me to approve before `/spec-apply`.
+7. Add the change as one line under "Open changes" in `BACKBONE.md`.
+8. Do not write code. Finish by showing the task list and asking me to approve before `/spec-apply`.

package/.claude/scripts/spec-check.mjs

@@ -0,0 +1,96 @@
+#!/usr/bin/env node
+
+/**
+ * Spec ↔ Test Traceability Check
+ * Every acceptance criterion `<capability>/AC-<n>` must be named by at least one test.
+ *
+ * Usage:
+ *   node .claude/scripts/spec-check.mjs                       # all of spec/specs/
+ *   node .claude/scripts/spec-check.mjs spec/changes/x.md     # one change (before archive)
+ */
+
+import { execSync } from 'child_process';
+import { readFileSync, readdirSync, existsSync } from 'fs';
+import { join, basename } from 'path';
+
+const AC_LINE = /\bAC-(\d+)\b/g;
+const TEST_REF = /([\w-]+)\/AC-(\d+)(?!\d)/g;
+
+// Acceptance criteria declared in a spec file. In a change file the capability
+// comes from the enclosing `### <capability> (new|modified)` heading.
+function declaredAcs(file, capability) {
+  const ids = new Set();
+  let current = capability;
+  let removed = false;
+  for (const line of readFileSync(file, 'utf-8').split('\n')) {
+    const cap = line.match(/^###\s+([\w-]+)\s+\((new|modified)\)/);
+    if (cap) current = cap[1];
+    if (/^####\s/.test(line)) removed = /^####\s+REMOVED\b/.test(line);
+    if (!current || removed || !/^\s*[-*]\s*AC-\d+/.test(line)) continue;
+    for (const m of line.matchAll(AC_LINE)) ids.add(`${current}/AC-${m[1]}`);
+  }
+  return ids;
+}
+
+const SKIP_DIRS = new Set(['.git', 'node_modules', 'dist', 'build', 'coverage', 'vendor', 'target', '.next']);
+
+// Multi-repo workspaces have no git repo at the root: walk the tree instead
+function walk(dir, out = []) {
+  for (const entry of readdirSync(dir, { withFileTypes: true })) {
+    if (entry.isDirectory()) {
+      if (!SKIP_DIRS.has(entry.name)) walk(join(dir, entry.name), out);
+    } else {
+      out.push(dir === '.' ? entry.name : join(dir, entry.name));
+    }
+  }
+  return out;
+}
+
+// AC references found in code/test files (everything except specs and docs)
+function referencedAcs() {
+  let files;
+  try {
+    files = execSync('git ls-files --cached --others --exclude-standard', { encoding: 'utf-8', stdio: ['pipe', 'pipe', 'ignore'] }).split('\n');
+  } catch {
+    files = walk('.');
+  }
+  const refs = new Set();
+  for (const file of files) {
+    if (!file || file.startsWith('spec/') || /\.(md|lock)$/.test(file) || !existsSync(file)) continue;
+    let text;
+    try {
+      text = readFileSync(file, 'utf-8');
+    } catch {
+      continue;
+    }
+    for (const m of text.matchAll(TEST_REF)) refs.add(`${m[1]}/AC-${m[2]}`);
+  }
+  return refs;
+}
+
+const target = process.argv[2];
+const declared = new Set();
+if (target) {
+  for (const id of declaredAcs(target)) declared.add(id);
+} else if (existsSync('spec/specs')) {
+  for (const f of readdirSync('spec/specs').filter((f) => f.endsWith('.md'))) {
+    for (const id of declaredAcs(join('spec/specs', f), basename(f, '.md'))) declared.add(id);
+  }
+}
+
+if (declared.size === 0) {
+  console.log('ℹ️  No acceptance criteria (AC-<n>) found.');
+  process.exit(0);
+}
+
+const refs = referencedAcs();
+const missing = [...declared].filter((id) => !refs.has(id)).sort();
+const covered = declared.size - missing.length;
+
+console.log(`📋 AC coverage: ${covered}/${declared.size}`);
+if (missing.length) {
+  console.log('❌ No test references:');
+  for (const id of missing) console.log(`   - ${id}`);
+  process.exit(1);
+}
+console.log('✅ Every AC is covered by a test.');

package/CLAUDE.md

@@ -9,6 +9,7 @@
 
 If it still holds `<placeholders>`, suggest `/backbone-init`. Follow its Invariants on every task.
 If you finish work without a spec that changes structure, docs, commands or capabilities, suggest `/backbone-sync`.
+Never invent business rules (money, limits, refunds, permissions, status transitions, legal): if no spec, invariant or doc states it, ask.
 
 ## 1. 🛑 Context & Token Preservation (Sub-20 Line Core)
 - Keep responses concise and targeted. Never dump entire files when diffs suffice.
@@ -21,6 +22,7 @@ If you finish work without a spec that changes structure, docs, commands or capa
 ## 2. 📋 Plan First Protocol (Anti-Drift)
 - For tasks touching **>= 2 files** or core architecture:
   - Generate a concise Plan before modifying files.
+  - Inside `/spec-apply`, the approved spec Tasks are the plan; do not write another one.
   - Research protocol: `.claude/rules/plan-mode-research.md`
   - Execution checklist: `.claude/rules/plan-mode-execution.md`
   - Validation steps: `.claude/rules/plan-mode-validation.md`

package/README.md

@@ -96,6 +96,13 @@ spec/
     └── data-export.md          ← current truth, merged on archive
 ```
 
+### Traceability (spec ↔ test)
+
+- Every acceptance criterion has an ID per capability: `- AC-2 expired QR: GIVEN ... WHEN ... THEN ...` in `spec/specs/refund.md` is `refund/AC-2`.
+- `/spec-apply` names tests with that ID: `describe("refund/AC-2: expired QR is refunded", ...)`.
+- `node .claude/scripts/spec-check.mjs [spec/changes/<name>.md]` lists ACs with no test (zero tokens, works in multi-repo workspaces). `/spec-archive` runs it before merging.
+- `BACKBONE.md` has a **Domain glossary** (Order, Payment, states...) so specs, code and tests use the same names.
+
 ### Example: a feature, end to end
 
 ```text

package/README.vi.md

@@ -96,6 +96,13 @@ spec/
     └── data-export.md          ← sự thật hiện tại, gộp vào khi archive
 ```
 
+### Truy vết (spec ↔ test)
+
+- Mỗi acceptance criterion có ID theo capability: dòng `- AC-2 QR hết hạn: GIVEN ... WHEN ... THEN ...` trong `spec/specs/refund.md` là `refund/AC-2`.
+- `/spec-apply` đặt tên test chứa ID đó: `describe("refund/AC-2: QR hết hạn thì hoàn tiền", ...)`.
+- `node .claude/scripts/spec-check.mjs [spec/changes/<tên>.md]` liệt kê AC chưa có test (không tốn token, chạy được cả workspace nhiều repo). `/spec-archive` tự chạy trước khi gộp.
+- `BACKBONE.md` có **Domain glossary** (Order, Payment, các trạng thái...) để spec, code và test dùng cùng một tên.
+
 ### Ví dụ: một feature từ đầu tới cuối
 
 ```text

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claudify-agent",
-  "version": "1.0.9",
+  "version": "1.0.11",
   "description": "Enterprise-grade workflow & context optimization framework for Claude Code, Claude Desktop, and AI coding agents.",
   "repository": {
     "type": "git",

package/templates/BACKBONE.md

@@ -14,6 +14,12 @@ Last synced: <commit> (<date>)
 |---|---|
 | <path> | <what lives there> |
 
+## Domain glossary
+<!-- The nouns of the business, as the team says them. Code, specs and tests use these names. -->
+| Term | Meaning | States / relations |
+|---|---|---|
+| <Order> | <one customer purchase> | <draft → paid → cancelled; has many OrderItem> |
+
 ## Docs index
 | Doc | About | Status |
 |---|---|---|

package/templates/spec/config.md

@@ -8,7 +8,8 @@
 
 ## Requirements
 - `#### ADDED|MODIFIED|REMOVED Requirement: <name>` containing SHALL or MUST.
-- Each has scenarios GIVEN / WHEN / THEN with concrete values: at least one happy path and one failure.
+- Each has ACs `- AC-<n> <name>: GIVEN / WHEN / THEN` with concrete values: at least one happy path and one failure.
+- AC IDs are per capability, never reused; tests name them as `<capability>/AC-<n>` (checked by `node .claude/scripts/spec-check.mjs`).
 
 ## Tasks
 - Each task fits in 2-4 hours, lists files/packages touched and its DoD.