agentic-sdd-framework 1.4.0
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/.agents/AGENTS.template.md +59 -0
- package/.agents/CONTEXT.template.md +41 -0
- package/.agents/ENTRYPOINT.template.md +31 -0
- package/.agents/skills/ast-navigator/SKILL.md +31 -0
- package/.agents/skills/ast-navigator/adapters/ast-grep.md +18 -0
- package/.agents/skills/ast-navigator/adapters/graphify.md +19 -0
- package/.agents/skills/ast-navigator/adapters/lsp.md +16 -0
- package/.agents/skills/ast-navigator/adapters/ripgrep.md +19 -0
- package/.agents/skills/auditor-executor-protocol/SKILL.md +410 -0
- package/.agents/skills/auditor-executor-protocol/references/autonomous-mode.md +144 -0
- package/.agents/skills/auditor-executor-protocol/references/failure-modes-and-example.md +103 -0
- package/.agents/skills/auditor-executor-protocol/references/handoffs.md +133 -0
- package/.agents/skills/auditor-executor-protocol/references/tasks-and-gates.md +81 -0
- package/.agents/skills/no-ai-slop/LICENSE +21 -0
- package/.agents/skills/no-ai-slop/SKILL.md +52 -0
- package/.agents/skills/strategic-cto/SKILL.md +54 -0
- package/CHANGELOG.md +117 -0
- package/LICENSE +21 -0
- package/README.md +244 -0
- package/docs/SPEC_TEMPLATE.md +78 -0
- package/docs/decisions/ADR_TEMPLATE.md +49 -0
- package/docs/guidelines/AST_NAVIGATION.md +51 -0
- package/docs/guides/AGENT_CREDENTIALS.md +75 -0
- package/docs/guides/GITHUB_CLI_SETUP.md +74 -0
- package/docs/incidents/0000-00-00-incident-template.md +35 -0
- package/docs/roadmap/templates/compliance-log.md +37 -0
- package/docs/roadmap/templates/execution-guide.md +75 -0
- package/docs/roadmap/templates/plan-of-record.md +49 -0
- package/package.json +49 -0
- package/scripts/check-copy-slop.js +120 -0
- package/scripts/check-file-size.js +66 -0
- package/scripts/check-spec.js +201 -0
- package/scripts/check-system-prerequisites.js +133 -0
- package/scripts/check-versions.js +50 -0
- package/scripts/dev/fuzz-spec-markup.js +123 -0
- package/scripts/dev/set-npm-publish-token.sh +40 -0
- package/scripts/dev/sync-vendored.js +94 -0
- package/scripts/install-git-hooks.js +103 -0
- package/scripts/lib/cli.js +60 -0
- package/scripts/lib/config.js +111 -0
- package/scripts/lib/git.js +211 -0
- package/scripts/lib/markdown.js +46 -0
- package/scripts/lib/provision.js +323 -0
- package/scripts/lib/runner.js +70 -0
- package/scripts/lib/sdd.config.schema.json +213 -0
- package/scripts/lib/slop-patterns.js +57 -0
- package/scripts/lib/spec-markup.js +346 -0
- package/scripts/lib/spec.js +226 -0
- package/scripts/lib/state.js +107 -0
- package/scripts/lib/vendor/README.md +11 -0
- package/scripts/lib/vendor/markdown-it.LICENSE +22 -0
- package/scripts/lib/vendor/markdown-it.min.js +3 -0
- package/scripts/quality-gate.js +151 -0
- package/scripts/sdd-init.js +245 -0
- package/scripts/sdd-verify.js +176 -0
- package/scripts/verify-no-secrets.js +216 -0
- package/sdd.config.json +33 -0
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to this project are documented in this file.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project
|
|
6
|
+
adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Install a specific release
|
|
7
|
+
with `npx github:tBeltty/agentic-sdd-framework#v<version>`.
|
|
8
|
+
|
|
9
|
+
## [Unreleased]
|
|
10
|
+
|
|
11
|
+
## [1.4.0] - 2026-09-25
|
|
12
|
+
|
|
13
|
+
Records written by 1.3.0 use the old format: run `sdd-verify --record` (and `sdd-verify --task`
|
|
14
|
+
for recorded evidence) again before pushing a `Completed` spec.
|
|
15
|
+
|
|
16
|
+
### Changed
|
|
17
|
+
- `Last Verified` now ends with `check <hash>`, a hash over the date, result, commit, exit code,
|
|
18
|
+
state, verification command, and expected output. Editing FAIL to PASS, or changing the command
|
|
19
|
+
or expected output after recording, reopens the spec. Recorded task evidence hashes the date and
|
|
20
|
+
exit code together with the transcript.
|
|
21
|
+
- `sdd-verify --record` refuses to run while untracked files exist; they took part in the run but
|
|
22
|
+
not in the recorded state.
|
|
23
|
+
- `sdd-init` reuses the answers stored in an existing `sdd.config.json` as defaults; only explicit
|
|
24
|
+
flags override them. The spec and Rigor documents are created at the configured
|
|
25
|
+
`specification.specFile` and `specification.roadmapDir`.
|
|
26
|
+
- Rigor mode requires `auditkit` 0.3.9 or newer, which tightens negative-control validation. CI
|
|
27
|
+
pins the protocol repository to v0.3.9.
|
|
28
|
+
- Check scripts reject unknown flags (a typo checked the working tree instead) and accept
|
|
29
|
+
`--ref <commit>` as well as `--ref=<commit>`.
|
|
30
|
+
- Config paths must be canonical (`docs/SPEC.md`, not `./docs/SPEC.md`), and `specFile` and
|
|
31
|
+
`roadmapDir` must not end with `/`; other forms broke the spec check.
|
|
32
|
+
- CI uses `actions/checkout@v7` and `actions/setup-node@v7`, which run on Node.js 24.
|
|
33
|
+
|
|
34
|
+
### Fixed
|
|
35
|
+
- Fixed how some tracked files (unusual names, very large content) were read for the secret scan.
|
|
36
|
+
- Fixed secrets not being scanned in some commits.
|
|
37
|
+
- Fixed a false positive on committed specs with CRLF line endings.
|
|
38
|
+
- Fixed a misleading failure in shallow clones.
|
|
39
|
+
- Fixed the spec parser disagreeing with GitHub on some Markdown, which could hide a task,
|
|
40
|
+
change the Status, or run a different verification command.
|
|
41
|
+
- Fixed a rare case where the spec parser could read a list item differently than GitHub does.
|
|
42
|
+
- Fixed a crash when the spec contains a table.
|
|
43
|
+
- Fixed a checked task that could be misread and skip validation.
|
|
44
|
+
- Fixed a hidden task not being detected in some cases.
|
|
45
|
+
- Fixed unclosed code fences being accepted when the spec requires them closed.
|
|
46
|
+
- Fixed `sdd-verify --task` misplacing evidence in some cases.
|
|
47
|
+
- Fixed `sdd-verify --task` silently deleting other task data in some cases.
|
|
48
|
+
- Fixed `sdd-verify --task` not checking for existing spec problems before writing evidence.
|
|
49
|
+
- Fixed where `sdd-verify --task` wrote evidence under numbered tasks.
|
|
50
|
+
- Fixed several false positives and false negatives in the secret scanner.
|
|
51
|
+
- Fixed which paths the secret scanner skips.
|
|
52
|
+
- Fixed a prose-check false positive where symlinks are unavailable.
|
|
53
|
+
- Fixed `scripts/dev/sync-vendored.js` accepting a mistyped flag.
|
|
54
|
+
- Fixed `sdd-verify` not killing background processes on timeout.
|
|
55
|
+
- Fixed the framework exemption in the specification check applying too broadly.
|
|
56
|
+
- Fixed the config validator accepting invalid keys.
|
|
57
|
+
- Fixed the prose linter's handling of a custom `roadmapDir`.
|
|
58
|
+
- Fixed `sdd-init`'s next steps and guided mode in some configurations.
|
|
59
|
+
- Fixed test cleanup and Windows hook tests.
|
|
60
|
+
|
|
61
|
+
## [1.3.0] - 2026-09-25
|
|
62
|
+
|
|
63
|
+
### Fixed
|
|
64
|
+
- Fixed the pre-push hook checking the working tree instead of the pushed commits.
|
|
65
|
+
- Fixed Git failures being swallowed instead of failing the check.
|
|
66
|
+
- Fixed `sdd.config.json` not being validated.
|
|
67
|
+
- Fixed several bypasses in the specification check.
|
|
68
|
+
- Fixed the secret scanner missing several kinds of credentials and secret files.
|
|
69
|
+
- Fixed `maxEmDashes` and the fence-closing rule.
|
|
70
|
+
- Fixed the pre-push hook installer writing into a shared hooks directory.
|
|
71
|
+
- Fixed `sdd-init` ignoring some flags and forms.
|
|
72
|
+
- `.claude/skills/` copies (used where symlinks are unavailable) were never refreshed; `--force`
|
|
73
|
+
refreshes them.
|
|
74
|
+
- `--staged` was inconsistent: the Rigor check and the version check read the working tree.
|
|
75
|
+
- Rigor mode accepted any `auditkit` version; it now requires 0.3.0 or newer.
|
|
76
|
+
|
|
77
|
+
### Added
|
|
78
|
+
- `sdd-verify --task <ID> -- <command>` records a command's transcript as task evidence with its
|
|
79
|
+
exit code and a hash; the gate rejects edited or failing recorded evidence, counts hand-written
|
|
80
|
+
evidence, and rejects it when `specification.requireRecordedEvidence` is true.
|
|
81
|
+
- `sdd-verify --record` writes a state fingerprint and fails when the command modifies tracked files.
|
|
82
|
+
- `specification.verifyTimeoutSeconds` (default 900) and `specification.verifyShell`.
|
|
83
|
+
- `quality-gate.js --ref=<commit>` and `--push [remote]`. In push mode, a ref whose commit is
|
|
84
|
+
already on the remote (such as a tag on a published commit) publishes nothing new and is skipped.
|
|
85
|
+
- `security.allowFiles` for tracked files with sensitive names.
|
|
86
|
+
- `.sdd/VERSION` in installed projects; the wizard reports tooling upgrades.
|
|
87
|
+
- CI runs on Linux, macOS, and Windows; `.gitattributes` keeps line endings consistent.
|
|
88
|
+
|
|
89
|
+
### Changed
|
|
90
|
+
- The README describes what the framework does and what each check enforces, including its limits.
|
|
91
|
+
- `package.json` no longer declares a `main` entry (requiring the package ran the wizard).
|
|
92
|
+
|
|
93
|
+
## [1.2.0] - 2026-09-25
|
|
94
|
+
|
|
95
|
+
### Added
|
|
96
|
+
- The quality gate checks the specification: Lite specs need evidence for checked tasks and a
|
|
97
|
+
recorded PASS to be completed; Rigor documents are checked with `auditkit lint`.
|
|
98
|
+
- `sdd-verify` runs the spec's verification command and records the result.
|
|
99
|
+
- Rigor documents use the auditkit format, vendored from auditor-executor-protocol, with a CI check
|
|
100
|
+
that the vendored files match the canonical repository.
|
|
101
|
+
|
|
102
|
+
## [1.1.0] - 2026-09-25
|
|
103
|
+
|
|
104
|
+
### Added
|
|
105
|
+
- Root `AGENTS.md`, `CLAUDE.md`, and `.claude/skills/` so agents load the rules without a prompt.
|
|
106
|
+
- Install into an existing project with `npx github:tBeltty/agentic-sdd-framework`.
|
|
107
|
+
- File size limit check; `node:test` suites; single-process quality gate.
|
|
108
|
+
|
|
109
|
+
### Changed
|
|
110
|
+
- Node.js 22 LTS or newer is required.
|
|
111
|
+
|
|
112
|
+
## [1.0.0] - 2026-09-02
|
|
113
|
+
|
|
114
|
+
### Added
|
|
115
|
+
- Initial release: constitution and context templates, Lite and Rigor specification templates,
|
|
116
|
+
strategic-cto, no-ai-slop, ast-navigator, and auditor-executor-protocol skills, bootstrapping
|
|
117
|
+
wizard, and quality gate scripts.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 tBeltty
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
# Agentic SDD Framework
|
|
2
|
+
|
|
3
|
+
> Spec-Driven Development governance for AI coding agents: agent rules that load automatically, specifications with recorded evidence, and a quality gate that checks both before every push.
|
|
4
|
+
|
|
5
|
+
[](https://opensource.org/licenses/MIT)
|
|
6
|
+
[](https://github.com/tBeltty/agentic-sdd-framework/actions)
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## 🎯 What It Does
|
|
11
|
+
|
|
12
|
+
AI coding agents (Claude Code, Antigravity, Cursor, Codex) write code quickly, and without constraints they also guess the stack, drift out of scope, and report work as done without running it. This framework adds three things to a repository:
|
|
13
|
+
|
|
14
|
+
1. **Agent rules that load without a prompt.** `AGENTS.md`, `CLAUDE.md`, and `.claude/skills/` point every supported agent at a constitution, an operational context file, and four on-demand skills.
|
|
15
|
+
2. **A specification with evidence.** Tasks are checked off with recorded command output, and a spec is completed only with a recorded verification run tied to the exact content it verified.
|
|
16
|
+
3. **A quality gate.** A pre-push hook checks the commits being pushed for secrets, prose rules, file size limits, and specification evidence.
|
|
17
|
+
|
|
18
|
+
```mermaid
|
|
19
|
+
graph LR
|
|
20
|
+
subgraph VibeCoding [Without a specification]
|
|
21
|
+
V1[Vague Prompt] --> V2[Agent Guesses Stack]
|
|
22
|
+
V2 --> V3[Unverified Multi-File Edits]
|
|
23
|
+
V3 --> V4[Regression Cascade]
|
|
24
|
+
end
|
|
25
|
+
|
|
26
|
+
subgraph AgenticSDD [With Agentic SDD]
|
|
27
|
+
S1[Constitution and Discovery] --> S2[Specification]
|
|
28
|
+
S2 --> S3[Atomic Tasks with Evidence]
|
|
29
|
+
S3 --> S4[Recorded Verification Gate]
|
|
30
|
+
end
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## 🧭 Progressive Rigor: Two Specification Modes
|
|
36
|
+
|
|
37
|
+
Projects begin simply and scale as architectural complexity grows. The mode is set in `sdd.config.json`:
|
|
38
|
+
|
|
39
|
+
```mermaid
|
|
40
|
+
graph TD
|
|
41
|
+
A[New Project or Feature] --> B{Choose Specification Depth}
|
|
42
|
+
B -->|Solo Dev / Lightweight MVP| C[Lite Mode - Default]
|
|
43
|
+
C --> C1[Single File: docs/SPEC.md]
|
|
44
|
+
C1 --> C2[Recorded Verification Gate]
|
|
45
|
+
B -->|Multi-Agent / Enterprise System| D[Rigor Mode]
|
|
46
|
+
D --> D1[Plan, Execution Guide, Compliance Log, Annexes]
|
|
47
|
+
D1 --> D2[Negative Control Gates]
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### 1. 🟢 Lite Mode (Default, Solo Developers)
|
|
51
|
+
* **Single Entry Point:** `docs/SPEC.md` holds context, architecture, atomic tasks, and the verification gate.
|
|
52
|
+
* **Recorded Evidence:** `sdd-verify --task <ID> -- <command>` runs a command and records its output as the task's evidence. `sdd-verify --record` runs the spec's verification command and records the result.
|
|
53
|
+
* **Best For:** Solo developers, utilities, early-stage MVPs.
|
|
54
|
+
|
|
55
|
+
### 2. 🔴 Rigor Mode (Opt-In, Multi-Agent Teams)
|
|
56
|
+
* **The Auditor-Executor document set** in `docs/roadmap/`, in the format of [auditor-executor-protocol](https://github.com/tBeltty/auditor-executor-protocol):
|
|
57
|
+
* `plan-of-record.md`: the "what" and "why" (phases and trade-offs).
|
|
58
|
+
* `execution-guide.md`: the "how" (numbered tasks `P<phase>-T<n>` and gates `P<phase>-G<n>`).
|
|
59
|
+
* `compliance-log.md`: the ledger of pasted command output and verdicts.
|
|
60
|
+
* `annexes/`: self-contained remediation orders issued after a verdict that is not a clean `APPROVED`.
|
|
61
|
+
* **Mechanical Checks:** the quality gate runs `auditkit lint` (0.3.9 or newer), which rejects missing or orphaned task entries, gates without a negative control, and `DONE` reports without pasted verify output.
|
|
62
|
+
* **Best For:** Multi-agent handoffs, asynchronous work, and regulated domains.
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## ⚡ Quickstart
|
|
67
|
+
|
|
68
|
+
**Requirements:** Git and Node.js 22 LTS or newer (24 LTS recommended), for projects in any language. Rigor mode also needs Python 3.9+ for `auditkit`:
|
|
69
|
+
|
|
70
|
+
```bash
|
|
71
|
+
pipx install git+https://github.com/tBeltty/auditor-executor-protocol
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 1. Install into a Project (Recommended)
|
|
75
|
+
Run the wizard from the root of a new or existing Git repository. Pin a release tag so a later change to `main` never reaches you unannounced (see [CHANGELOG.md](CHANGELOG.md)):
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
cd my-project
|
|
79
|
+
npx github:tBeltty/agentic-sdd-framework#v1.4.0
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Express mode skips the interview and takes every answer from flags:
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
npx github:tBeltty/agentic-sdd-framework#v1.4.0 --express --mode=lite --ast=ast-grep --runtime=go-1.23
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### 2. Start from a Clone
|
|
89
|
+
Use the framework repository itself as the starting point of a new project:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
git clone --branch v1.4.0 https://github.com/tBeltty/agentic-sdd-framework.git my-project
|
|
93
|
+
cd my-project
|
|
94
|
+
node scripts/sdd-init.js
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Wizard Flags
|
|
98
|
+
|
|
99
|
+
Flags take `--flag=value` or `--flag value`. Unknown flags are an error.
|
|
100
|
+
|
|
101
|
+
| Flag | Values | Default |
|
|
102
|
+
| :--- | :--- | :--- |
|
|
103
|
+
| `--express` | Non-interactive run | Guided mode on a terminal |
|
|
104
|
+
| `--target=<dir>` | Project to provision | Current directory |
|
|
105
|
+
| `--name=<name>` | Project name | Target directory name |
|
|
106
|
+
| `--runtime=<id>` | `node-24-lts`, `go-1.23`, `python-3.12`, ... | `node-24-lts` |
|
|
107
|
+
| `--mode=<mode>` | `lite`, `rigor` | `lite` |
|
|
108
|
+
| `--ast=<adapter>` | `ast-grep`, `graphify`, `ripgrep`, `lsp` | `ast-grep` |
|
|
109
|
+
| `--concurrency=`, `--hardware=`, `--workload=` | Discovery answers recorded in ADR-0001 | Small internal service |
|
|
110
|
+
| `--i18n`, `--pwa` | Enable the capability flags | Disabled |
|
|
111
|
+
| `--force` | Refresh copied skills, templates, and `.claude/skills/` copies | Keep existing copies |
|
|
112
|
+
| `--help` | Print usage | |
|
|
113
|
+
|
|
114
|
+
Rerunning the wizard is safe. Existing documents are kept, `sdd.config.json` is merged and validated (keys starting with `x-` are free-form), and `AGENTS.md` / `CLAUDE.md` are only rewritten while they carry the `sdd:managed` marker. If they already exist without it, the wizard says so and prints the line to add.
|
|
115
|
+
|
|
116
|
+
### What the Wizard Generates
|
|
117
|
+
|
|
118
|
+
| Path | Purpose |
|
|
119
|
+
| :--- | :--- |
|
|
120
|
+
| `AGENTS.md` | Entry point read automatically by Codex, Cursor, and other AGENTS.md-aware agents |
|
|
121
|
+
| `CLAUDE.md` | Imports the entry point, constitution, and context into Claude Code |
|
|
122
|
+
| `.claude/skills/` | Symlinks to `.agents/skills/` (copies where symlinks are unavailable) so Claude Code loads each skill on demand |
|
|
123
|
+
| `.agents/AGENTS.md` | Constitution: 8 non-negotiable rules, each with a "Why this rule exists" field |
|
|
124
|
+
| `.agents/CONTEXT.md` | Project facts, incident registry, technical debt, and non-goals |
|
|
125
|
+
| `docs/SPEC.md` (Lite) or `docs/roadmap/` (Rigor) | Active specification documents, checked by the quality gate |
|
|
126
|
+
| `docs/decisions/ADR-0001-stack-and-architecture.md` | Stack decision record seeded with the discovery answers |
|
|
127
|
+
| `sdd.config.json` | Configuration, validated against [`scripts/lib/sdd.config.schema.json`](scripts/lib/sdd.config.schema.json) |
|
|
128
|
+
| `.sdd/scripts/`, `.sdd/VERSION` | Quality gate tooling and its version (install mode only) |
|
|
129
|
+
| Git `pre-push` hook | Runs the quality gate on the pushed commits; an existing hook is kept as `pre-push.local` and runs first |
|
|
130
|
+
|
|
131
|
+
When `core.hooksPath` is set (Husky, lefthook, or a shared hooks directory), the wizard installs nothing there and prints the command to add to that hook manager instead.
|
|
132
|
+
|
|
133
|
+
---
|
|
134
|
+
|
|
135
|
+
## 🚦 Quality Gate
|
|
136
|
+
|
|
137
|
+
`node scripts/quality-gate.js` (`node .sdd/scripts/quality-gate.js` in installed projects) runs every check in one process and exits 1 if any fails. Each run reads files from one source:
|
|
138
|
+
|
|
139
|
+
| Invocation | Checks |
|
|
140
|
+
| :--- | :--- |
|
|
141
|
+
| *(no flag)* | Tracked files in the working tree |
|
|
142
|
+
| `--staged` | The index: what the next commit contains |
|
|
143
|
+
| `--ref=<commit>` or `--ref <commit>` | The content of that commit |
|
|
144
|
+
| `--push [remote]` | Pre-push mode (used by the hook): every check on the tip commit of each pushed ref, plus a secret scan of every new commit in the push (merge commits included), so a secret added and later removed is still caught. Refs whose commit is already on the remote are skipped |
|
|
145
|
+
|
|
146
|
+
Unknown flags are errors, so a typo never falls back to checking the working tree. A check that cannot read the repository (not a Git repository, Git error, unreadable file) fails; it never reports "0 files, all clean". An invalid `sdd.config.json` (unknown key, wrong type, unknown value) fails every check with the exact problem.
|
|
147
|
+
|
|
148
|
+
| Check | Script | Configuration (`sdd.config.json`) |
|
|
149
|
+
| :--- | :--- | :--- |
|
|
150
|
+
| Secret leak scanner | `verify-no-secrets.js` | `security.allowFiles`; the `sdd-allow-secret` line pragma (suppressions are counted in the report) |
|
|
151
|
+
| No-AI-Slop copy linter | `check-copy-slop.js` | `capabilities.noAiSlop.enabled`, `.exclude`, `.maxEmDashes` |
|
|
152
|
+
| File size limit | `check-file-size.js` | `architecture.maxLocPerFile` (0 disables), `architecture.maxLocExclude` |
|
|
153
|
+
| Specification check | `check-spec.js` | `specification.mode`, `.specFile`, `.roadmapDir`, `.requireRecordedEvidence` |
|
|
154
|
+
| Version sync | `check-versions.js` | Applies only when `project.type` is `framework` |
|
|
155
|
+
|
|
156
|
+
The secret scanner reports provider keys (Anthropic, OpenAI, Stripe, GitHub, Slack, Resend, AWS, Google), private key blocks (including PGP), credentials embedded in URLs, high-entropy values assigned to secret-named keys (`password`, `client_secret`, `access_token`, `SECRET_KEY`, `signing_key`, ...; unquoted values count in env, config, rc, shell, and Docker files), and tracked secret files (`.env`, `id_rsa`, `*.key`, `*.p12`, ...). It skips only its own file at the paths the framework installs it (`scripts/` and `.sdd/scripts/`) and `node_modules/` directories; lockfiles are scanned, since a private-registry URL can embed a token. It is a regex scanner, not a replacement for a dedicated tool such as gitleaks.
|
|
157
|
+
|
|
158
|
+
### What the Specification Check Enforces
|
|
159
|
+
|
|
160
|
+
| Mode | Rule |
|
|
161
|
+
| :--- | :--- |
|
|
162
|
+
| Lite, any status | Exactly one Status line: `Draft`, `In Progress`, or `Completed`; the `Verification Gate` section exists; every checked task (any checkbox list item, blockquotes included) has evidence; the spec stays within the supported Markdown subset (below) |
|
|
163
|
+
| Lite, recorded evidence | Evidence written by `sdd-verify --task` must be unedited (the hash covers the date, exit code, and transcript) and exit 0 |
|
|
164
|
+
| Lite, hand-written evidence | Accepted and counted in the report; rejected when `specification.requireRecordedEvidence` is `true` |
|
|
165
|
+
| Lite, `In Progress` | The verification command and expected output are filled in, not template placeholders |
|
|
166
|
+
| Lite, `Completed` | Every task is checked, and `Last Verified` is an unedited PASS written by `sdd-verify --record` for the current verification command and expected output, whose state fingerprint matches the content the spec was completed with |
|
|
167
|
+
| Rigor | `auditkit lint docs/roadmap` exits 0 |
|
|
168
|
+
|
|
169
|
+
The gate reads the spec the way it renders: it parses it with a CommonMark parser (markdown-it, vendored in `scripts/lib/vendor/`, MIT) and takes tasks, the Status, the evidence, and the verification command from the parsed structure, so a line counts only if it renders as what it claims to be. On top of that, a small subset keeps GitHub's renderer and the parser in agreement: no raw HTML outside code (HTML comments included), no link reference definitions or footnotes (inline links only), no HTML entities or invisible and non-ASCII whitespace characters, spaces instead of tabs for indentation, and the Status and gate fields written exactly as in the template (a line that reads as a field name followed by a colon, or emphasized, in any other spelling is an error). Code is taken verbatim. Anything else fails with the line number and what to change; the template and everything `sdd-verify` writes stay inside the subset. `scripts/dev/fuzz-spec-markup.js` compares the gate's reading with cmark-gfm, GitHub's renderer, on random specs.
|
|
170
|
+
|
|
171
|
+
`sdd-verify --record` runs the spec's verification command, checks that every expected line appears in the output (`/.../` lines are regular expressions), fails if the command modified tracked files, and writes `Last Verified: <date> PASS|FAIL (commit <sha>, exit <code>, state <fingerprint>, check <hash>)`. The fingerprint covers every tracked file except the spec. The check hash covers the other fields plus the verification command and expected output, so editing the result, or changing the command after recording, reopens the spec. `--record` refuses to run while there are untracked files, because they would take part in the run without being part of the recorded state; commit, ignore, or remove them first. The gate recomputes it for the commit that completed the spec (or the uncommitted state), so files changed after the verification invalidate the PASS. Later commits that do not touch the spec do not reopen it: catching regressions after a spec is closed is the job of CI and tests.
|
|
172
|
+
|
|
173
|
+
Commands run in `specification.verifyShell` (default `/bin/sh` on macOS and Linux, `cmd.exe` on Windows) with a limit of `specification.verifyTimeoutSeconds` (default 900). The gate never runs a command from the spec itself; it only checks recorded results. On timeout the whole process tree is killed, including background processes the command started.
|
|
174
|
+
|
|
175
|
+
The check finds the commit that completed the spec in the Git history, so CI needs the full history: in GitHub Actions, use `actions/checkout` with `fetch-depth: 0`. In a shallow clone the check fails and says so.
|
|
176
|
+
|
|
177
|
+
The hashes are integrity checks, not signatures: they catch hand edits and stale records, but anyone who can run `sdd-verify` can also write a matching record. For an authoritative result, have CI run `sdd-verify` again. Recorded evidence also cannot prove a verification command is meaningful; that remains the reviewer's call.
|
|
178
|
+
|
|
179
|
+
`check-system-prerequisites.js` (Git identity, `gh` authentication, SSH keys) runs once inside the wizard and is available as `npm run check:prereqs`. It is not part of the gate because it depends on the local machine, not on the code.
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
## 🧠 Repository Layout
|
|
184
|
+
|
|
185
|
+
```text
|
|
186
|
+
agentic-sdd-framework/
|
|
187
|
+
├── .agents/
|
|
188
|
+
│ ├── AGENTS.template.md # Constitution template (8 rules)
|
|
189
|
+
│ ├── CONTEXT.template.md # Operational memory template
|
|
190
|
+
│ ├── ENTRYPOINT.template.md # Root AGENTS.md template
|
|
191
|
+
│ └── skills/
|
|
192
|
+
│ ├── strategic-cto/ # 4-Pillar Discovery, Anti-Bloat, ROI Verdict
|
|
193
|
+
│ ├── auditor-executor-protocol/ # Execution protocol (tBeltty/auditor-executor-protocol)
|
|
194
|
+
│ ├── no-ai-slop/ # Factual copy rules (petergyang/no-ai-slop)
|
|
195
|
+
│ └── ast-navigator/ # Pluggable adapters (graphify, ast-grep, ripgrep, lsp)
|
|
196
|
+
│
|
|
197
|
+
├── docs/
|
|
198
|
+
│ ├── SPEC_TEMPLATE.md # Lite Mode template
|
|
199
|
+
│ ├── decisions/ADR_TEMPLATE.md # Architecture Decision Record template
|
|
200
|
+
│ ├── roadmap/templates/ # Rigor Mode templates (vendored from auditkit)
|
|
201
|
+
│ ├── incidents/ # Post-mortem template
|
|
202
|
+
│ ├── guides/ # Credential tiers, GitHub CLI setup
|
|
203
|
+
│ └── guidelines/ # AST navigation adapter comparison
|
|
204
|
+
│
|
|
205
|
+
├── scripts/
|
|
206
|
+
│ ├── sdd-init.js # Bootstrapping wizard (guided and express)
|
|
207
|
+
│ ├── quality-gate.js # Runs every check (working tree, index, commit, or push)
|
|
208
|
+
│ ├── verify-no-secrets.js # Credential scanner
|
|
209
|
+
│ ├── check-copy-slop.js # No-AI-Slop linter
|
|
210
|
+
│ ├── check-file-size.js # maxLocPerFile enforcement
|
|
211
|
+
│ ├── check-spec.js # Specification evidence check
|
|
212
|
+
│ ├── sdd-verify.js # Runs and records verification commands and task evidence
|
|
213
|
+
│ ├── check-versions.js # Framework version sync
|
|
214
|
+
│ ├── check-system-prerequisites.js # Day-0 Git, gh CLI, and SSH checks
|
|
215
|
+
│ ├── install-git-hooks.js # pre-push hook installer
|
|
216
|
+
│ ├── lib/ # Git sources, config schema, spec parser, provisioning
|
|
217
|
+
│ └── dev/sync-vendored.js # Syncs and checks files vendored from auditor-executor-protocol
|
|
218
|
+
│
|
|
219
|
+
├── test/ # node:test suites (npm test)
|
|
220
|
+
├── CHANGELOG.md # Release notes
|
|
221
|
+
└── sdd.config.json # Configuration of this repository
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
---
|
|
225
|
+
|
|
226
|
+
## 📜 Open-Source Attributions
|
|
227
|
+
|
|
228
|
+
The **Agentic SDD Framework** integrates, adapts, or provides adapters for the following open-source projects:
|
|
229
|
+
|
|
230
|
+
| Component | Author / Organization | Upstream Repository | License | Role |
|
|
231
|
+
| :--- | :--- | :--- | :--- | :--- |
|
|
232
|
+
| **Auditor-Executor Protocol** | **tBeltty** | [tBeltty/auditor-executor-protocol](https://github.com/tBeltty/auditor-executor-protocol) | MIT | Multi-agent coordination, Rigor Mode documents, and negative control gates. |
|
|
233
|
+
| **Spec-Kit Concepts** | **GitHub** | [github/spec-kit](https://github.com/github/spec-kit) | MIT | Progressive specification hierarchy, unified single-spec model, and interactive constitution. |
|
|
234
|
+
| **No-AI-Slop** | **Peter Yang** | [petergyang/no-ai-slop](https://github.com/petergyang/no-ai-slop) | MIT | Writing rules behind the copy linter. |
|
|
235
|
+
| **Graphify** | **Graphify Labs** | [Graphify-Labs/graphify](https://github.com/Graphify-Labs/graphify) | Apache 2.0 | Relational knowledge graph adapter for code navigation. |
|
|
236
|
+
| **ast-grep** | **Herrington Darkholme** | [ast-grep/ast-grep](https://github.com/ast-grep/ast-grep) | MIT | Tree-sitter structural search adapter. |
|
|
237
|
+
| **ripgrep** | **Andrew Gallant** | [BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep) | MIT / Unlicense | Regex text search adapter. |
|
|
238
|
+
| **SCIP / LSP** | **SCIP Code** (originally Sourcegraph) | [scip-code/scip](https://github.com/scip-code/scip) | Apache 2.0 | Language Server Protocol code intelligence adapter. |
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
## 🛡️ License
|
|
243
|
+
|
|
244
|
+
This repository is licensed under the [MIT License](LICENSE). The vendored `no-ai-slop` skill keeps its upstream MIT license ([`.agents/skills/no-ai-slop/LICENSE`](.agents/skills/no-ai-slop/LICENSE)).
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Feature Specification: [Feature Name]
|
|
2
|
+
|
|
3
|
+
**Specification Mode:** Lite (Single-Document Execution)
|
|
4
|
+
**Status:** Draft | In Progress | Completed
|
|
5
|
+
**Author:** [Author Name]
|
|
6
|
+
**Target Completion:** [Date]
|
|
7
|
+
|
|
8
|
+
> The quality gate enforces this document. Status must be `Draft`, `In Progress`, or `Completed`. A checked task needs evidence: record it with `sdd-verify --task <ID> -- <command>`, or paste the command and its output. `In Progress` and `Completed` need a real verification command and expected output. `Completed` needs every task checked and a PASS recorded by `sdd-verify --record` for the exact content being completed; change a file afterwards and the PASS no longer counts. Keep to plain Markdown (spaces for indentation, closed fences, no raw HTML or comments, inline links only): the gate rejects markup it cannot read exactly as it renders.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. Context and Problem Statement
|
|
13
|
+
|
|
14
|
+
State the exact problem or user requirement. Document the operational root cause or feature motivation without filler or marketing language.
|
|
15
|
+
|
|
16
|
+
* **Current Behavior:** Describe what happens today.
|
|
17
|
+
* **Desired Behavior:** Describe what should happen after implementation.
|
|
18
|
+
* **Non-Goals:** Explicitly list what this change will not address.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 2. Technical Architecture and Constraints
|
|
23
|
+
|
|
24
|
+
List every component, file, and interface impacted by this specification.
|
|
25
|
+
|
|
26
|
+
* **Components Affected:**
|
|
27
|
+
* Component A: [Brief description of changes]
|
|
28
|
+
* Component B: [Brief description of changes]
|
|
29
|
+
* **Data Models & Contracts:** Detail input/output schemas, schema migrations, or API payloads.
|
|
30
|
+
* **Dependencies:** Name any external libraries needed. If none, state "None".
|
|
31
|
+
* **Architectural Boundaries:** State constraints (for example: Domain must not import Infrastructure).
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## 3. Implementation Tasks
|
|
36
|
+
|
|
37
|
+
List atomic, sequential tasks. Each task must name target files and concrete actions. Check a task only after pasting the command you ran and its literal output under **Evidence**.
|
|
38
|
+
|
|
39
|
+
* [ ] **T1:** [Action description]
|
|
40
|
+
* **Files:** `path/to/fileA.ext`
|
|
41
|
+
* **Details:** Specific functions, types, or configuration keys to add or modify.
|
|
42
|
+
* **Evidence:** [command run and its literal output]
|
|
43
|
+
* [ ] **T2:** [Action description]
|
|
44
|
+
* **Files:** `path/to/fileB.ext`
|
|
45
|
+
* **Details:** Integration and orchestration logic.
|
|
46
|
+
* **Evidence:** [command run and its literal output]
|
|
47
|
+
* [ ] **T3:** [Action description]
|
|
48
|
+
* **Files:** `path/to/tests/feature.test.ext`
|
|
49
|
+
* **Details:** Unit and integration test coverage.
|
|
50
|
+
* **Evidence:** [command run and its literal output]
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 4. Verification Gate
|
|
55
|
+
|
|
56
|
+
The specification is not complete until this command exits with code 0 and returns expected output. `sdd-verify --record` runs it in `/bin/sh` (macOS, Linux) or `cmd.exe` (Windows) unless `specification.verifyShell` says otherwise, and checks that every non-empty line of the expected output appears in the actual output (a line wrapped in `/slashes/` is a regular expression).
|
|
57
|
+
|
|
58
|
+
* **Verification Command:**
|
|
59
|
+
```bash
|
|
60
|
+
[command to run tests or validation scripts]
|
|
61
|
+
```
|
|
62
|
+
* **Expected Output:**
|
|
63
|
+
```text
|
|
64
|
+
[exact pattern or output line confirming success]
|
|
65
|
+
```
|
|
66
|
+
* **Manual Verification (If applicable):** Specific manual steps to observe expected behavior.
|
|
67
|
+
* **Last Verified:** [recorded by sdd-verify --record]
|
|
68
|
+
|
|
69
|
+
`sdd-verify --record` writes `Last Verified` with a hash over the result, the command, and the expected output. Do not edit it by hand: changing any of them reopens the spec until you record again.
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## 5. Decision Rationale
|
|
74
|
+
|
|
75
|
+
Record trade-offs and alternatives rejected during implementation.
|
|
76
|
+
|
|
77
|
+
* **Decision 1:** [Why option A was selected over option B].
|
|
78
|
+
* **Origin:** [Incident, performance measurement, or architectural requirement driving the decision].
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# ADR-[NNNN]: [Decision Title]
|
|
2
|
+
|
|
3
|
+
**Status:** Accepted | Proposed | Superseded
|
|
4
|
+
**Date:** [YYYY-MM-DD]
|
|
5
|
+
**Deciders:** [Author / Team]
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## 1. Context and Problem Statement
|
|
10
|
+
|
|
11
|
+
Document the application requirements and the results of the **4-Pillar Discovery Interview**:
|
|
12
|
+
|
|
13
|
+
1. **Scale and Concurrency:** Target users (e.g. 1–10 internal users vs 50,000 public users). Concurrency peaks expected in Year 1.
|
|
14
|
+
2. **Hardware and Deployment:** Target runtime environment (e.g. $5 VPS, local machine, cloud containers). Memory and CPU bounds.
|
|
15
|
+
3. **Data and Workload:** Primary operations (I/O-heavy, CPU-intensive, static storage vs live compute). Data persistence volume.
|
|
16
|
+
4. **Modularity and Localization:** Requirement for multi-language translation (i18n), PWA offline caching, role-based access.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## 2. Decision and Selected Stack
|
|
21
|
+
|
|
22
|
+
State the selected technologies across each layer of the application:
|
|
23
|
+
|
|
24
|
+
* **Backend Runtime & Framework:** [e.g. Go with standard net/http, Node.js 24 LTS with Hono, Python 3.12 with FastAPI]
|
|
25
|
+
* **Frontend Architecture:** [e.g. Static Single Page Application (Vite + React), Server-Rendered HTML, CLI tool]
|
|
26
|
+
* **Persistence Engine:** [e.g. SQLite with WAL mode, PostgreSQL 16, Flat JSON files]
|
|
27
|
+
* **Code Navigation Adapter:** [e.g. Graphify, ast-grep, ripgrep]
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## 3. Anti-Bloat Burden of Proof
|
|
32
|
+
|
|
33
|
+
Explain why simpler architectural tiers were accepted or discarded:
|
|
34
|
+
|
|
35
|
+
* **Tier 1 Evaluation (Ultra-Lightweight):** [Why Tier 1 was selected, or why it lacked required capability].
|
|
36
|
+
* **Tier 2 Evaluation (Balanced):** [Why Tier 2 was selected, or why it was bypassed].
|
|
37
|
+
* **Tier 3 Evaluation (Heavy Batteries):** If choosing a heavy full-stack framework (such as Next.js SSR or Django), document the mandatory technical reason that simpler stacks could not satisfy.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 4. Consequences and Trade-Offs
|
|
42
|
+
|
|
43
|
+
### Positive Consequences:
|
|
44
|
+
* Minimal memory footprint and predictable resource consumption.
|
|
45
|
+
* Fast continuous integration build times.
|
|
46
|
+
* Clear isolation of domain logic and infrastructure.
|
|
47
|
+
|
|
48
|
+
### Negative Consequences and Mitigations:
|
|
49
|
+
* [Document trade-offs accepted, such as manual routing or lack of monolithic magic].
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# 🧭 Codebase Navigation: AST First and Token Efficiency
|
|
2
|
+
|
|
3
|
+
This guide establishes the codebase exploration protocol for developers and autonomous AI agents using the **Agentic SDD Framework**.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. The Core Problem: Context Bloat and Token Exhaustion
|
|
8
|
+
|
|
9
|
+
Traditional agent exploration relies on running broad `grep` commands or dumping whole source files into model context. This approach causes three compounding failures:
|
|
10
|
+
|
|
11
|
+
1. **Context Saturation:** Reading five 800-line files consumes 20,000+ tokens before any code is written.
|
|
12
|
+
2. **Loss of Precision:** Agents struggle with needle-in-a-haystack symbol tracing when flooded with irrelevant function bodies.
|
|
13
|
+
3. **Financial Cost:** Monorepo exploration costs scale linearly with repository lines of code.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 2. The Solution: AST-First Hierarchy
|
|
18
|
+
|
|
19
|
+
Always follow the three-tier exploration hierarchy:
|
|
20
|
+
|
|
21
|
+
```text
|
|
22
|
+
Step 1: AST / Graph Query (Locate symbol, caller, or interface definition)
|
|
23
|
+
│
|
|
24
|
+
▼ (If not found or graph stale)
|
|
25
|
+
Step 2: Scoped Grep (Search bounded by file extension or directory glob)
|
|
26
|
+
│
|
|
27
|
+
▼ (After locating exact line bounds)
|
|
28
|
+
Step 3: Slice Inspection (Read only target lines, e.g. lines 40 to 80)
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## 3. Objective Comparison of Navigation Adapters
|
|
34
|
+
|
|
35
|
+
| Adapter | Upstream Creator | Mechanism | Best For | Trade-offs |
|
|
36
|
+
| :--- | :--- | :--- | :--- | :--- |
|
|
37
|
+
| **`graphify`** | Graphify Labs | Relational graph + visual extraction | Monorepos, cross-layer dependency tracing | Requires Python 3.10+; index requires updates after edits. |
|
|
38
|
+
| **`ast-grep`** | Herrington Darkholme | Tree-sitter structural syntax matching | Syntax-aware structural grep, code migrations | Requires language parser support; no whole-repo graph visualization. |
|
|
39
|
+
| **`ripgrep`** | Andrew Gallant | Line-oriented SIMD regex engine | Fast text search, markdown/config inspection | Does not understand semantic code structure or imports. |
|
|
40
|
+
| **`lsp / scip`** | SCIP Code (originally Sourcegraph) | Language Server Protocol type indexing | Enterprise TypeScript, Go, Java, Rust | Heavier initial indexing pipeline; language-specific setups. |
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## 4. How to Select Your Active Adapter
|
|
45
|
+
|
|
46
|
+
In `sdd.config.json`, set the adapter under `capabilities.astNavigation.adapter`:
|
|
47
|
+
|
|
48
|
+
* Choose **`graphify`** if you work in a medium-to-large multi-service monorepo and have Python available.
|
|
49
|
+
* Choose **`ast-grep`** if you want zero Python dependencies and fast structural syntax matching.
|
|
50
|
+
* Choose **`ripgrep`** if you are building a small project and prefer standard text utilities.
|
|
51
|
+
* Choose **`lsp`** if your primary language relies heavily on complex compiler type hierarchies.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# 🔐 Zero-Trust Secret Architecture & Credential Registry
|
|
2
|
+
|
|
3
|
+
This document establishes the **Three-Tier Secret Isolation Model** for repositories managed with the **Agentic SDD Framework**.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 🏛️ The Three-Tier Secret Isolation Model
|
|
8
|
+
|
|
9
|
+
AI agents are powerful code executors, but they must be treated under a **Zero-Trust Model**. Secrets are categorized into three isolated tiers to ensure credentials can never be leaked through code, git history, or agent context logs.
|
|
10
|
+
|
|
11
|
+
```text
|
|
12
|
+
┌────────────────────────────────────────────────────────┐
|
|
13
|
+
│ Tier 1: Production Host Secrets │
|
|
14
|
+
│ - Stored ONLY on production hosts (VPS/Cloud) │
|
|
15
|
+
│ - Read directly by the running application process │
|
|
16
|
+
│ - Never checked into Git, never in developer workspaces │
|
|
17
|
+
└────────────────────────────────────────────────────────┘
|
|
18
|
+
▲
|
|
19
|
+
┌────────────────────────────────────────────────────────┐
|
|
20
|
+
│ Tier 2: CI/CD Execution Secrets │
|
|
21
|
+
│ - Stored in GitHub Actions Secrets │
|
|
22
|
+
│ - Injected ephemeral into runner memory │
|
|
23
|
+
│ - Masked automatically from build & test logs │
|
|
24
|
+
└────────────────────────────────────────────────────────┘
|
|
25
|
+
▲
|
|
26
|
+
┌────────────────────────────────────────────────────────┐
|
|
27
|
+
│ Tier 3: Agent Diagnostic Vault (OUTSIDE REPOSITORY) │
|
|
28
|
+
│ - Location: ~/secrets/<project-name>/.vault │
|
|
29
|
+
│ - Filesystem permissions: chmod 600 (User-only read) │
|
|
30
|
+
│ - Agent reads from disk; NEVER asks user to paste keys │
|
|
31
|
+
└────────────────────────────────────────────────────────┘
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 🚨 Inviolable Rules for AI Coding Agents
|
|
37
|
+
|
|
38
|
+
1. **NEVER Ask the User to Paste a Secret in Chat:**
|
|
39
|
+
Asking the user to paste an API key or password into a conversation stores that credential in model training logs and session history.
|
|
40
|
+
2. **NEVER Write Secrets to Tracked Files:**
|
|
41
|
+
Credentials must never be hardcoded into source code, test files, configs, or markdown artifacts.
|
|
42
|
+
3. **NEVER Log Credentials to Console or Files:**
|
|
43
|
+
Avoid `console.log(process.env)` or printing authorization headers during debugging.
|
|
44
|
+
4. **Always Read from the Tier 3 Vault:**
|
|
45
|
+
When an agent requires read-only diagnostic access (e.g. Sentry API, GitHub API, Cloudflare API), it must read directly from `~/secrets/<project-name>/.vault` using local filesystem read tools.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## 🛠️ Setting Up the Tier 3 Local Vault
|
|
50
|
+
|
|
51
|
+
Run this setup once on your local developer machine:
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
# 1. Create secure secrets directory outside of any git repository
|
|
55
|
+
mkdir -p ~/secrets/<project-name>
|
|
56
|
+
|
|
57
|
+
# 2. Create the vault file
|
|
58
|
+
touch ~/secrets/<project-name>/.vault
|
|
59
|
+
|
|
60
|
+
# 3. Restrict permissions to owner-only read/write
|
|
61
|
+
chmod 600 ~/secrets/<project-name>/.vault
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Format of `.vault`:
|
|
65
|
+
```bash
|
|
66
|
+
# Key-value pairs read by diagnostic tools
|
|
67
|
+
GITHUB_TOKEN=gho_xxxxxxxxxxxxxxxxxxxx
|
|
68
|
+
SENTRY_AUTH_TOKEN=sntrys_xxxxxxxxxxxxxxxxxxxx
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## 🛡️ Pre-Commit Verification Scanner
|
|
74
|
+
|
|
75
|
+
Before committing code, the repository enforces `scripts/verify-no-secrets.js`. Any commit containing a staged secret or private key will be blocked immediately.
|