arcane-cli 0.29.3 → 0.29.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/assets/.arcane/governance/decision-documentation-standard.md +14 -6
- package/dist/assets/.arcane/governance/development-methodology.md +10 -4
- package/dist/assets/.arcane/governance/portable-bootstrap.md +7 -5
- package/dist/assets/.arcane/governance/product-excellence-standards.md +15 -1
- package/dist/assets/.arcane/governance/rca-process-standard.md +11 -7
- package/package.json +1 -1
|
@@ -35,8 +35,8 @@ Arcane separates framework-level decisions from org-specific ones using two pref
|
|
|
35
35
|
|
|
36
36
|
- If the decision would apply to any organization using Arcane, it is `ARC-NNN`.
|
|
37
37
|
- If the decision is specific to how your organization operates, it is `ADR-NNN`.
|
|
38
|
-
- When uncertain, default to `ADR-NNN` in ops; promote to `ARC-NNN` later if the decision proves framework-generic.
|
|
39
|
-
- Never renumber existing entries in either sequence.
|
|
38
|
+
- When uncertain, default to `ADR-NNN` in ops; promote to `ARC-NNN` later if the decision proves framework-generic. **Enforcement: explicitly advisory prose (ARC-023) — whether a decision is framework-generic enough for `ARC-NNN` (this rule and the two prefix-scoping rules above) is a judgment call; no script evaluates a decision's content to confirm the chosen prefix.**
|
|
39
|
+
- Never renumber existing entries in either sequence. **Enforcement: explicitly advisory prose (ARC-023) — `scripts/check-distributed-adr-references.ts` only verifies that a bare `ADR-NNN` citation resolves to a heading declared in `framework-decisions.md` (and separately flags certain `ARC-NNN`/`EF-NNN` link forms as cross-repo hazards); it never checks that numbers are sequential, unique, or never reused.**
|
|
40
40
|
|
|
41
41
|
## Problem Statement
|
|
42
42
|
|
|
@@ -64,7 +64,7 @@ Arcane separates framework-level decisions from org-specific ones using two pref
|
|
|
64
64
|
- Rejected alternatives (2-3 bullets: what was considered but not chosen)
|
|
65
65
|
- **Deep dive link** (if companion doc exists): `[[path/to/detail-doc|Display Text]]`
|
|
66
66
|
|
|
67
|
-
**Keep ADRs under 20 lines** (excluding frontmatter). Longer means detail should move to companion doc.
|
|
67
|
+
**Keep ADRs under 20 lines** (excluding frontmatter). Longer means detail should move to companion doc. **Enforcement: explicitly advisory prose (ARC-023) — no script measures ADR entry length in DECISIONS.md; the Quarterly Review checklist below asks a human to check for long ADRs manually.**
|
|
68
68
|
|
|
69
69
|
**Naming Impact Check:** If the decision introduces, changes, or retires a name (repo, project, product, agent, service), the ADR **must** include a "Naming impact" section that:
|
|
70
70
|
|
|
@@ -72,7 +72,7 @@ Arcane separates framework-level decisions from org-specific ones using two pref
|
|
|
72
72
|
2. Confirms no collision with other entities
|
|
73
73
|
3. Identifies any docs, scripts, or prompts that reference the old name
|
|
74
74
|
|
|
75
|
-
This check was added after [[governance/rcas/RCA-001-naming-collision|RCA-001]] discovered that ADR-061 named a product without checking whether the ops repo already used that name.
|
|
75
|
+
This check was added after [[governance/rcas/RCA-001-naming-collision|RCA-001]] discovered that ADR-061 named a product without checking whether the ops repo already used that name. **Enforcement: explicitly advisory prose (ARC-023) — no script or spell gate verifies that an ADR introducing a new name actually contains a "Naming impact" section or performed its three checks; `spell-scry` can run the grep-and-collision check manually, but nothing requires it before such an ADR is written.**
|
|
76
76
|
|
|
77
77
|
### Tier 2: Companion Detail Docs
|
|
78
78
|
|
|
@@ -243,13 +243,13 @@ Create "Related ADRs" section at the top of every companion doc:
|
|
|
243
243
|
- [[DECISIONS#ADR-NNN|Git SSH Authentication decision]]
|
|
244
244
|
```
|
|
245
245
|
|
|
246
|
-
**Rationale:** Creates bidirectional graph edges in Obsidian visualization. Clicking an ADR shows its authentication strategy companion; the companion links back to each related ADR.
|
|
246
|
+
**Rationale:** Creates bidirectional graph edges in Obsidian visualization. Clicking an ADR shows its authentication strategy companion; the companion links back to each related ADR. **Enforcement: explicitly advisory prose (ARC-023) — no script verifies that a companion doc's "Related ADRs" section reciprocates an ADR's "Deep dive" link, or that every companion doc has one at all; the Anti-Patterns section below lists forgetting this link as a known failure mode with no automated catch.**
|
|
247
247
|
|
|
248
248
|
---
|
|
249
249
|
|
|
250
250
|
## Index-Free Discovery
|
|
251
251
|
|
|
252
|
-
**No DECISIONS-INDEX.md required.** Discovery happens via:
|
|
252
|
+
**No DECISIONS-INDEX.md required. Enforcement: explicitly advisory prose (ARC-023) — nothing prevents creating one, and no script verifies that the four discovery methods below actually surface a given decision.** Discovery happens via:
|
|
253
253
|
|
|
254
254
|
1. **Obsidian Graph View:** Visual clusters show related docs
|
|
255
255
|
2. **Wiki-link navigation:** Click ADR "Deep dive" link → companion doc → "Related ADRs" → back to other ADRs
|
|
@@ -287,6 +287,8 @@ Create "Related ADRs" section at the top of every companion doc:
|
|
|
287
287
|
- If new companion doc needed, create it first, then add "Deep dive" link in ADR
|
|
288
288
|
- If existing companion doc covers it, add new section to that doc + update "Related ADRs" list
|
|
289
289
|
|
|
290
|
+
**Enforcement: explicitly advisory prose (ARC-023) — none of the editorial steps above (bumping `last_updated`, extracting detail past 20 lines, adding or updating "Deep dive"/"Related ADRs" links) is checked by any script; each depends on the editor remembering to do it.**
|
|
291
|
+
|
|
290
292
|
### Quarterly Review
|
|
291
293
|
|
|
292
294
|
Every 3 months:
|
|
@@ -296,6 +298,8 @@ Every 3 months:
|
|
|
296
298
|
- [ ] Verify Obsidian graph shows connected clusters (no isolated decision nodes)
|
|
297
299
|
- [ ] Review "Future Considerations" sections in companion docs — any re-evaluation triggers?
|
|
298
300
|
|
|
301
|
+
**Enforcement: explicitly advisory prose (ARC-023) — this is a manual checklist; no script detects orphaned companion docs, measures ADR length, verifies Obsidian graph connectivity, or reminds anyone to revisit "Future Considerations" sections.**
|
|
302
|
+
|
|
299
303
|
---
|
|
300
304
|
|
|
301
305
|
## Anti-Patterns (Don't Do This)
|
|
@@ -312,6 +316,8 @@ Every 3 months:
|
|
|
312
316
|
|
|
313
317
|
❌ **Putting rationale in journals instead of companion docs** — Journals are chronological session logs (narrative). Companion docs are topic-indexed reference (structured). Rationale goes in companion docs, linked from journals.
|
|
314
318
|
|
|
319
|
+
**Enforcement: explicitly advisory prose (ARC-023) — no lint or script detects any of the six anti-patterns above (a stray `ADR-NNN-deep-dive.md` file, duplicated content, implementation steps in a companion doc, a companion doc for a simple decision, a missing bidirectional link, or rationale left in a journal); catching them depends on the writer's or a reviewer's judgment.**
|
|
320
|
+
|
|
315
321
|
---
|
|
316
322
|
|
|
317
323
|
## Evolution of This Standard
|
|
@@ -324,6 +330,8 @@ Every 3 months:
|
|
|
324
330
|
4. Add entry to DECISIONS.md if decision-making process itself changes
|
|
325
331
|
5. Announce in relevant channels (if the team expands beyond a single operator)
|
|
326
332
|
|
|
333
|
+
**Enforcement: explicitly advisory prose (ARC-023) — no script or spell gate enforces this five-step process when this standard itself changes; it depends on the editor following it by discipline.**
|
|
334
|
+
|
|
327
335
|
**Versioning note:** Per-business decisions follow this pattern — business-only decisions live in `ventures/{name}/DECISIONS.md` (unnumbered or business-prefixed); system/cross-business decisions stay in the root `DECISIONS.md`.
|
|
328
336
|
|
|
329
337
|
---
|
|
@@ -141,9 +141,11 @@ Child linkage rules:
|
|
|
141
141
|
3. If the selected fallback type combination cannot be linked as parent/child in that process template, use `Related` links and prefix titles with logical level tags (for example: `[EPIC]`, `[FEATURE]`) to preserve intent.
|
|
142
142
|
4. Never silently flatten hierarchy. Document fallback/link decisions in `execution-plan.md` notes.
|
|
143
143
|
|
|
144
|
+
**Enforcement: explicitly advisory prose (ARC-023) — no script verifies the fallback order was followed or that `execution-plan.md` documents a link decision; compliance depends entirely on the executing agent's judgment.**
|
|
145
|
+
|
|
144
146
|
### GitHub Issues Conventions
|
|
145
147
|
|
|
146
|
-
When `tracking_mode=external` and `external_provider=github`, resolve `{owner}/{repo}` from `git remote get-url origin` (or `.arcane.json`'s `github.repo` field if set) rather than assuming it matches the working directory name.
|
|
148
|
+
When `tracking_mode=external` and `external_provider=github`, **resolve `{owner}/{repo}` from `git remote get-url origin` (or `.arcane.json`'s `github.repo` field if set) rather than assuming it matches the working directory name. Enforcement: explicitly advisory prose (ARC-023) — no script gates this resolution before issue-tracking commands run; a same-principle utility (`parseGitHubRemote` in `src/modules/platform-policy.ts`) exists but serves `doctor`'s branch-policy check, not this workflow.**
|
|
147
149
|
|
|
148
150
|
GitHub Issues has no configurable work-item-type hierarchy the way Azure DevOps does — there is no process-template discovery step, and no equivalent to `az boards work-item-type list`. Use these substitutes instead:
|
|
149
151
|
|
|
@@ -194,6 +196,8 @@ Without this chain, agents make conflicting decisions across stories (e.g., one
|
|
|
194
196
|
3. Check for missing test coverage, architecture violations, security issues
|
|
195
197
|
4. Defer unrelated findings to a backlog (don't derail the current change)
|
|
196
198
|
|
|
199
|
+
**Enforcement: explicitly advisory prose (ARC-023) — no script counts or verifies findings, and `spell-review.prompt.md`'s current Rules section has superseded item 1's minimum with "no finding quota... zero findings is a valid outcome," so this minimum should be read as superseded framing, not current spell behavior.**
|
|
200
|
+
|
|
197
201
|
### Append-Only Progress
|
|
198
202
|
|
|
199
203
|
`progress.txt` is never edited, only appended. Each iteration adds:
|
|
@@ -248,6 +252,8 @@ The Arcane story schema for autonomous implementation:
|
|
|
248
252
|
|
|
249
253
|
If the output is missing required tracking fields, `passes`, `assignedTo`, `priority`, or `testEvidence`, it is malformed and must be regenerated.
|
|
250
254
|
|
|
255
|
+
**Enforcement: structured spell gate (ARC-023) — `spell-architect` step 5a self-checks every field and must regenerate before outputting if any is missing, and `spell-full-cycle` Phase 2 independently gates on the same schema completeness before proceeding to Phase 3; no external schema-validator script exists, so the check is agent-administered, not tool-verified.**
|
|
256
|
+
|
|
251
257
|
### Story Sizing
|
|
252
258
|
|
|
253
259
|
Each story must be small enough to complete in one context window:
|
|
@@ -275,7 +281,7 @@ For features that should run end-to-end with minimal human intervention, use `sp
|
|
|
275
281
|
spell-full-cycle = spell-plan → [spell-enchant] → spell-architect → [spell-implement → spell-test → spell-review]* → spell-ship
|
|
276
282
|
```
|
|
277
283
|
|
|
278
|
-
The entire pipeline runs autonomously with a single human gate at PR approval. Includes optional PRD enchantment between Plan and Architect (runs automatically if any quality dimension scores Bronze, or if `--enchant` is specified). Requires three inputs: feature description, tracking configuration (`tracking_mode` and optional `external_provider`), and target repo. In ADO mode, include the ADO work item ID; in GitHub mode, include the issue number if one already exists. Each phase has built-in quality gates that halt the pipeline on failure rather than producing garbage for downstream phases.
|
|
284
|
+
The entire pipeline runs autonomously with a single human gate at PR approval. Includes optional PRD enchantment between Plan and Architect (runs automatically if any quality dimension scores Bronze, or if `--enchant` is specified). Requires three inputs: feature description, tracking configuration (`tracking_mode` and optional `external_provider`), and target repo. In ADO mode, include the ADO work item ID; in GitHub mode, include the issue number if one already exists. **Each phase has built-in quality gates that halt the pipeline on failure rather than producing garbage for downstream phases. Enforcement: structured spell gate (ARC-023) — `spell-full-cycle.prompt.md` encodes explicit per-phase `Gate:` steps (e.g., Phase 4: "If coverage is below threshold or any acceptance criterion lacks a test, loop back to Phase 3... Maximum 2 coverage-fix loops before halting"; Phase 5: "If any HIGH severity finding exists, loop back to Phase 3... Maximum 2 review-fix loops before halting") plus a human/authority gate before merge.**
|
|
279
285
|
|
|
280
286
|
See [.github/prompts/spell-full-cycle.prompt.md](../.github/prompts/spell-full-cycle.prompt.md) for the complete prompt.
|
|
281
287
|
|
|
@@ -299,7 +305,7 @@ spell-plan → [spell-enchant] → spell-scope → [spell-architect → spell-im
|
|
|
299
305
|
|
|
300
306
|
Each epic then runs through its own Spell Loop cycle (architect → implement → test → review → ship).
|
|
301
307
|
|
|
302
|
-
Before starting the next epic after a major output checkpoint (execution plan, architecture + stories, full test evidence, or ship recommendation), run `spell-commit-work` to preserve progress and checkpoint branch state.
|
|
308
|
+
**Before starting the next epic after a major output checkpoint (execution plan, architecture + stories, full test evidence, or ship recommendation), run `spell-commit-work` to preserve progress and checkpoint branch state. Enforcement: explicitly advisory prose (ARC-023) — `spell-full-cycle.prompt.md`'s Rules section frames this as a recommendation ("recommend running `spell-commit-work` before starting the next epic"), and nothing blocks epic-start if it is skipped.**
|
|
303
309
|
|
|
304
310
|
See [.github/prompts/spell-scope.prompt.md](../.github/prompts/spell-scope.prompt.md) for the complete prompt.
|
|
305
311
|
|
|
@@ -323,7 +329,7 @@ When GitHub Copilot, Claude in VS Code, or any other interactive AI tool (not an
|
|
|
323
329
|
|
|
324
330
|
### Rule: Interactive tools cannot self-validate
|
|
325
331
|
|
|
326
|
-
A tool that writes code **must not
|
|
332
|
+
A tool that writes code **must not also run `spell-review` on that same code. Enforcement: explicitly advisory prose (ARC-023) — no mechanism in this repo can detect that the same agent or session both wrote and reviewed a diff (no session-identity tracking exists); GitHub's own block on self-authored `CHANGES_REQUESTED` reviews operates on GitHub account identity, not agent/session identity, and this repo routinely reuses one account for both.** This is the same constraint that prevents Lafayette from marking his own stories as passing. Specifically:
|
|
327
333
|
|
|
328
334
|
- Copilot sessions count as implementation (`spell-implement` equivalent)
|
|
329
335
|
- `spell-test` must be run to produce test evidence before review
|
|
@@ -15,7 +15,7 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
|
|
|
15
15
|
|
|
16
16
|
**Arcane** — Operational documentation for running AI-automated businesses under {LLC_NAME} (owner: {OPERATOR_NAME}). Uses an agent runtime to automate operations across one or more ventures.
|
|
17
17
|
|
|
18
|
-
**This is a documentation-only repository.** No build commands, test suites, or deployable code. Do not add automation without being asked.
|
|
18
|
+
**This is a documentation-only repository.** No build commands, test suites, or deployable code. **Do not add automation without being asked. Enforcement: explicitly advisory prose (ARC-023) — no check blocks adding scripts, build tooling, or automation to this repo; compliance depends on agent judgment.**
|
|
19
19
|
|
|
20
20
|
## Environment
|
|
21
21
|
|
|
@@ -26,6 +26,8 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
|
|
|
26
26
|
|
|
27
27
|
## Non-Negotiable Rules
|
|
28
28
|
|
|
29
|
+
**Enforcement note (ARC-023):** these 9 rules are a condensed restatement of `.arcane/governance/universal-agent-rules.md` rules 1-6, 10, 11, and 15 — see that file for each rule's full text and its authoritative enforcement-mode classification; this summary does not duplicate those classifications here, to avoid a second, driftable copy of the same information.
|
|
30
|
+
|
|
29
31
|
1. **Never access an encrypted or cross-OS volume you are not authorized to touch.** This rule stands as defense-in-depth regardless of encryption status.
|
|
30
32
|
2. **No root commands** unless explicitly scoped and justified.
|
|
31
33
|
3. **No secrets on the command line.** Use env vars and `read -s`.
|
|
@@ -49,20 +51,20 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
|
|
|
49
51
|
|
|
50
52
|
## Where Documents Live
|
|
51
53
|
|
|
52
|
-
- **Framework-managed standards:** `.arcane/governance/`. Spells reference this single installed layer; do not create a duplicate root `governance/` tree.
|
|
54
|
+
- **Framework-managed standards:** `.arcane/governance/`. Spells reference this single installed layer; **do not create a duplicate root `governance/` tree. Enforcement: explicitly advisory prose (ARC-023) — no check scans a repo for a duplicate root-level `governance/` directory.**
|
|
53
55
|
- **Project-owned orientation and continuity:** `README.md`, `project.md`, `TODO.md`, `DECISIONS.md`, `ai-context/`, and `journal/`. Arcane creates missing files once and preserves existing content.
|
|
54
56
|
- **Project/domain documents:** use explicit descriptive paths such as `docs/`, `security/`, `infrastructure/`, or a configured business root. These add project context alongside framework standards.
|
|
55
|
-
- **Overrides are not yet supported:** editing a managed `.arcane/governance/` standard can be replaced by `arcane update`. Additive project documents are safe; overriding a shipped standard requires the open customization/override model.
|
|
57
|
+
- **Overrides are not yet supported:** editing a managed `.arcane/governance/` standard can be replaced by `arcane update`. Additive project documents are safe; **overriding a shipped standard requires the open customization/override model. Enforcement: explicitly advisory prose (ARC-023) — that model is still an open backlog item (not yet built), so nothing currently blocks a direct edit; `arcane update` will just overwrite it silently on the next run.**
|
|
56
58
|
|
|
57
59
|
## Research Reports
|
|
58
60
|
|
|
59
61
|
Research findings (competitive analysis, technical spikes, feasibility studies — the output of the Research & Backlog Analyst role) live at `docs/research/<topic-slug>.md`, one file per report. No dedicated spell produces these: `spell-document` already proposes a target path from project structure and matches its destination directory's existing conventions — point it at `docs/research/` for investigative content, the same way it already proposes `docs/` or `.arcane/governance/` for other document types. The directory is created on first real report, not pre-seeded on `spell init`.
|
|
60
62
|
|
|
61
|
-
Use this repo's standard frontmatter (below) plus one addition: `sources` — a list of what was consulted. Every claim in the body traces back to one of these or is explicitly marked speculative. Structure the body summary-first: a short **Summary** with the key findings, then **Findings** with full detail and inline citations, then an optional **Follow-ups** for anything that should become a TODO item — route those via `spell-todo`, which cross-references the report path. Throughout, distinguish **verified facts**, **reasonable inferences**, and **speculation** explicitly; don't let an inference read as a checked fact.
|
|
63
|
+
Use this repo's standard frontmatter (below) plus one addition: `sources` — a list of what was consulted. **Every claim in the body traces back to one of these or is explicitly marked speculative. Enforcement: explicitly advisory prose (ARC-023) — no mechanism reads research-report prose to verify citation coverage or speculation marking.** Structure the body summary-first: a short **Summary** with the key findings, then **Findings** with full detail and inline citations, then an optional **Follow-ups** for anything that should become a TODO item — route those via `spell-todo`, which cross-references the report path. Throughout, distinguish **verified facts**, **reasonable inferences**, and **speculation** explicitly; don't let an inference read as a checked fact.
|
|
62
64
|
|
|
63
65
|
## Documentation Format
|
|
64
66
|
|
|
65
|
-
Every doc uses YAML frontmatter: `title`, `audience` (human/ai/both), `last_updated`, `status` (draft/active/deprecated), `tags`. Use wiki-links (`[[filename]]`) for cross-references.
|
|
67
|
+
**Every doc uses YAML frontmatter: `title`, `audience` (human/ai/both), `last_updated`, `status` (draft/active/deprecated), `tags`. Enforcement: explicitly advisory prose (ARC-023) — no schema validates these frontmatter fields on arbitrary docs; `.arcane.json` manifest validation (`src/modules/manifest.ts`) covers only installation-config fields, not document frontmatter.** Use wiki-links (`[[filename]]`) for cross-references.
|
|
66
68
|
|
|
67
69
|
## Naming Tiers
|
|
68
70
|
|
|
@@ -25,6 +25,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
25
25
|
| **Dependency identification** | External services, APIs, and decisions the feature depends on are listed |
|
|
26
26
|
| **Open questions documented** | Unresolved items are captured — not ignored or assumed |
|
|
27
27
|
|
|
28
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
29
|
+
|
|
28
30
|
### 2. User Experience (UX)
|
|
29
31
|
|
|
30
32
|
| Criterion | Description |
|
|
@@ -38,6 +40,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
38
40
|
| **Consistency** | UI patterns, terminology, and behavior are consistent across features |
|
|
39
41
|
| **Micro-interactions** | Transitions, hover effects, and subtle animations provide polish without slowing users down |
|
|
40
42
|
|
|
43
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
44
|
+
|
|
41
45
|
### 3. Accessibility (WCAG 2.1 AA Baseline)
|
|
42
46
|
|
|
43
47
|
| Criterion | Description |
|
|
@@ -51,6 +55,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
51
55
|
| **Motion sensitivity** | Animations respect `prefers-reduced-motion`; no content-critical motion |
|
|
52
56
|
| **Text resizing** | UI remains usable at 200% zoom |
|
|
53
57
|
|
|
58
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
59
|
+
|
|
54
60
|
### 4. Performance
|
|
55
61
|
|
|
56
62
|
| Criterion | Description |
|
|
@@ -63,6 +69,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
63
69
|
| **Offline / degraded** | Define behavior when network is slow or unavailable (if applicable) |
|
|
64
70
|
| **Concurrent users** | Target number documented; load testing plan defined for > 100 concurrent |
|
|
65
71
|
|
|
72
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
73
|
+
|
|
66
74
|
### 5. Security (Beyond OWASP Baseline)
|
|
67
75
|
|
|
68
76
|
| Criterion | Description |
|
|
@@ -76,6 +84,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
76
84
|
| **Secret handling** | No hardcoded secrets; all credentials via environment variables or secret store |
|
|
77
85
|
| **Dependency scanning** | Third-party packages audited for known vulnerabilities |
|
|
78
86
|
|
|
87
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
88
|
+
|
|
79
89
|
### 6. Responsive Design
|
|
80
90
|
|
|
81
91
|
| Criterion | Description |
|
|
@@ -85,6 +95,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
85
95
|
| **Layout adaptation** | Content reflows appropriately — no horizontal scrolling on mobile |
|
|
86
96
|
| **Navigation adaptation** | Desktop nav collapses to mobile pattern (hamburger, bottom nav, etc.) |
|
|
87
97
|
|
|
98
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
99
|
+
|
|
88
100
|
### 7. Competitive Differentiation
|
|
89
101
|
|
|
90
102
|
| Criterion | Description |
|
|
@@ -94,6 +106,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
|
|
|
94
106
|
| **Table-stakes coverage** | Features that users expect as standard for this category are all present |
|
|
95
107
|
| **Experience premium** | At least one UX element that makes users think "this is well-made" |
|
|
96
108
|
|
|
109
|
+
**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
|
|
110
|
+
|
|
97
111
|
---
|
|
98
112
|
|
|
99
113
|
## Quality Profiles
|
|
@@ -160,7 +174,7 @@ If the user does not specify a profile, **Public MVP** is the default. Rationale
|
|
|
160
174
|
| **Could-Add** | Current score already meets or exceeds target; enhancement is aspirational |
|
|
161
175
|
| **Won't-Add** | Explicitly excluded regardless of profile |
|
|
162
176
|
|
|
163
|
-
**Override:** Security and Accessibility gaps are always at least Should-Add regardless of profile. A Bronze Security score is always Must-Add.
|
|
177
|
+
**Override:** Security and Accessibility gaps are always at least Should-Add regardless of profile. A Bronze Security score is always Must-Add. **Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant`'s own tier-assignment step and Rules section restate this override verbatim, so it is not purely aspirational text, but enforcement is still agent judgment during suggestion generation rather than a mechanical check; the user retains final approval over every addition, security and accessibility included.**
|
|
164
178
|
|
|
165
179
|
---
|
|
166
180
|
|
|
@@ -27,14 +27,18 @@ An RCA is **required** when any of these occur:
|
|
|
27
27
|
| **Implicit decision detected** | A drift check or session applied a change that had no governing ADR |
|
|
28
28
|
| **Integration failure from doc mismatch** | A playbook or script failed because docs disagreed with reality |
|
|
29
29
|
|
|
30
|
+
**Enforcement: explicitly advisory prose (ARC-023) — no script or drift check detects decision reversals, naming collisions, multi-file corrections, or the other trigger conditions above, or confirms an RCA was opened when one applies; recognizing a trigger and initiating an RCA depends on human or agent judgment.**
|
|
31
|
+
|
|
30
32
|
An RCA is **recommended** (but optional) for:
|
|
31
33
|
- Repeated confusion in sessions about the same topic
|
|
32
34
|
- A TODO item that was deferred and caused downstream problems
|
|
33
35
|
- Any incident where the operator says "how did we end up here?"
|
|
34
36
|
|
|
37
|
+
**Enforcement: explicitly advisory prose (ARC-023) — these are softer signals than the required triggers above; no script detects them, and opening an RCA here is left to human or agent judgment.**
|
|
38
|
+
|
|
35
39
|
## RCA Template
|
|
36
40
|
|
|
37
|
-
Every RCA follows this structure. Artifacts are stored in `governance/rcas/` with the filename `RCA-NNN-short-slug.md` (sequential numbering, matching the related ADR when applicable).
|
|
41
|
+
**Every RCA follows this structure. Artifacts are stored in `governance/rcas/` with the filename `RCA-NNN-short-slug.md` (sequential numbering, matching the related ADR when applicable). Enforcement: explicitly advisory prose (ARC-023) — no script validates RCA filenames, sequential numbering, or template structure.**
|
|
38
42
|
|
|
39
43
|
```markdown
|
|
40
44
|
---
|
|
@@ -117,7 +121,7 @@ When a trigger condition is met:
|
|
|
117
121
|
|
|
118
122
|
- **Corrective actions** fix the immediate problem (e.g., rename the files, revert the change)
|
|
119
123
|
- **Preventive actions** change the process so the problem can't recur (e.g., add a checklist item, amend a template, update a prompt)
|
|
120
|
-
- Every preventive action must reference the specific governance doc, template, or prompt it modifies
|
|
124
|
+
- **Every preventive action must reference the specific governance doc, template, or prompt it modifies. Enforcement: explicitly advisory prose (ARC-023) — no script verifies that a preventive action's Target Doc cites a real, specific governance path.**
|
|
121
125
|
|
|
122
126
|
### 4. Implement and Verify
|
|
123
127
|
|
|
@@ -126,8 +130,8 @@ When a trigger condition is met:
|
|
|
126
130
|
|
|
127
131
|
### 5. Close
|
|
128
132
|
|
|
129
|
-
- Set RCA status to `active` (RCAs remain active as reference — they are not "resolved" and deleted)
|
|
130
|
-
- Link the RCA from the related ADR using a "Deep dive" wiki-link
|
|
133
|
+
- **Set RCA status to `active` (RCAs remain active as reference — they are not "resolved" and deleted). Enforcement: explicitly advisory prose (ARC-023) — no script checks RCA status fields or blocks deleting an RCA file.**
|
|
134
|
+
- **Link the RCA from the related ADR using a "Deep dive" wiki-link. Enforcement: explicitly advisory prose (ARC-023) — `check-distributed-adr-references.ts` validates ADR-ID references and cross-repo link hazards but does not check for a "Deep dive" backlink from the ADR.**
|
|
131
135
|
- Record a note in the session journal
|
|
132
136
|
|
|
133
137
|
## Severity Levels
|
|
@@ -138,7 +142,7 @@ RCAs do not have formal severity levels. The trigger conditions above determine
|
|
|
138
142
|
|
|
139
143
|
- In interactive sessions: the human operator and AI agent collaborate on the RCA
|
|
140
144
|
- For autonomous agent work: the agent flags the trigger condition and drafts the RCA for human review
|
|
141
|
-
- RCAs are never auto-committed — they require human approval (same rule as all interactive commits per [[governance/git-conventions|Git Conventions]])
|
|
145
|
+
- **RCAs are never auto-committed — they require human approval (same rule as all interactive commits per [[governance/git-conventions|Git Conventions]]). Enforcement: structured spell gate (ARC-023) — this restates universal-agent-rules.md rule 10 ("Never auto-commit during interactive sessions"), enforced by `spell-commit-work`'s Step 8, which computes an approval fingerprint over the staged diff and message and halts until an authenticated operator response is tied to it before `git commit` runs.**
|
|
142
146
|
|
|
143
147
|
## Artifact Location
|
|
144
148
|
|
|
@@ -153,5 +157,5 @@ governance/
|
|
|
153
157
|
|
|
154
158
|
## Maintenance
|
|
155
159
|
|
|
156
|
-
- Review RCA preventive actions quarterly during `spell-check-drift` runs
|
|
157
|
-
- If a preventive action proves ineffective (same class of problem recurs), update the RCA with a "Recurrence" section and strengthen the preventive action
|
|
160
|
+
- **Review RCA preventive actions quarterly during `spell-check-drift` runs. Enforcement: explicitly advisory prose (ARC-023) — `spell-check-drift` has no RCA-specific detector; this cross-reference depends on the operator or agent remembering to do the review by hand.**
|
|
161
|
+
- **If a preventive action proves ineffective (same class of problem recurs), update the RCA with a "Recurrence" section and strengthen the preventive action. Enforcement: explicitly advisory prose (ARC-023) — no script detects recurrence of the same class of problem; recognizing it depends on human or agent judgment.**
|