@nurix/etna 0.19.20 → 0.19.22
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/data/harness-index.json +1 -1
- package/data/harnesses/code/.prettierignore +6 -0
- package/data/harnesses/code/CLAUDE.md +15 -14
- package/data/harnesses/code/agents/maintenance.md +1 -1
- package/data/harnesses/code/codex/agents/maintenance.toml +1 -1
- package/data/harnesses/code/harness.json +2 -2
- package/data/harnesses/code/skills/boundary/SKILL.md +1 -1
- package/data/harnesses/code/skills/brainstorm/SKILL.md +1 -1
- package/data/harnesses/code/skills/documentation/SKILL.md +64 -107
- package/data/harnesses/code/skills/documentation/references/examples.md +83 -7
- package/data/harnesses/code/skills/documentation/references/frontmatter.md +44 -0
- package/data/harnesses/code/skills/documentation/references/style-guide.md +44 -19
- package/data/harnesses/code/skills/documentation/references/untemplated.md +38 -0
- package/data/harnesses/code/skills/documentation/scripts/doc-lint.mjs +117 -0
- package/data/harnesses/code/skills/documentation/templates/Readme.md +31 -0
- package/data/harnesses/code/skills/documentation/templates/api-reference.md +20 -0
- package/data/harnesses/code/skills/documentation/templates/architecture-decision.md +121 -0
- package/data/harnesses/code/skills/documentation/templates/backlog.md +33 -0
- package/data/harnesses/code/skills/documentation/templates/changelog-entry.md +62 -0
- package/data/harnesses/code/skills/documentation/templates/changelog-index.md +41 -0
- package/data/harnesses/code/skills/documentation/templates/docs-readme.md +70 -0
- package/data/harnesses/code/skills/documentation/templates/domain-model.md +30 -0
- package/data/harnesses/code/skills/documentation/templates/environment-registry.md +15 -0
- package/data/harnesses/code/skills/documentation/templates/feature.md +149 -0
- package/data/harnesses/code/skills/documentation/templates/glossary.md +11 -0
- package/data/harnesses/code/skills/documentation/templates/memory-main.md +25 -0
- package/data/harnesses/code/skills/documentation/templates/migration-runbook.md +34 -0
- package/data/harnesses/code/skills/documentation/templates/non-goals.md +11 -0
- package/data/harnesses/code/skills/documentation/templates/operations-procedure.md +36 -0
- package/data/harnesses/code/skills/documentation/templates/plan.md +64 -0
- package/data/harnesses/code/skills/documentation/templates/protected-files.md +37 -0
- package/data/harnesses/code/skills/documentation/templates/root-readme.md +104 -0
- package/data/harnesses/code/skills/documentation/templates/security-overview.md +27 -0
- package/data/harnesses/code/skills/documentation/templates/structure.md +65 -0
- package/data/harnesses/code/skills/documentation/templates/system-overview.md +32 -0
- package/data/harnesses/code/skills/documentation/templates/testing-strategy.md +29 -0
- package/data/harnesses/code/skills/workflow-mapper/SKILL.md +1 -1
- package/data/harnesses/discover/.prettierignore +6 -0
- package/data/harnesses/discover/CLAUDE.md +11 -12
- package/data/harnesses/discover/harness.json +2 -2
- package/data/harnesses/discover/tooling-recommendations.md +10 -10
- package/data/harnesses/discussion/.prettierignore +6 -0
- package/data/harnesses/discussion/harness.json +1 -1
- package/data/harnesses/etna/.prettierignore +6 -0
- package/data/harnesses/etna/CLAUDE.md +12 -11
- package/data/harnesses/etna/agents/maintenance.md +1 -1
- package/data/harnesses/etna/codex/agents/maintenance.toml +1 -1
- package/data/harnesses/etna/harness.json +2 -2
- package/data/harnesses/etna/skills/boundary/SKILL.md +1 -1
- package/data/harnesses/etna/skills/brainstorm/SKILL.md +1 -1
- package/data/harnesses/etna/skills/documentation/SKILL.md +64 -107
- package/data/harnesses/etna/skills/documentation/references/examples.md +83 -7
- package/data/harnesses/etna/skills/documentation/references/frontmatter.md +44 -0
- package/data/harnesses/etna/skills/documentation/references/style-guide.md +44 -19
- package/data/harnesses/etna/skills/documentation/references/untemplated.md +38 -0
- package/data/harnesses/etna/skills/documentation/scripts/doc-lint.mjs +117 -0
- package/data/harnesses/etna/skills/documentation/templates/Readme.md +31 -0
- package/data/harnesses/etna/skills/documentation/templates/api-reference.md +20 -0
- package/data/harnesses/etna/skills/documentation/templates/architecture-decision.md +121 -0
- package/data/harnesses/etna/skills/documentation/templates/backlog.md +33 -0
- package/data/harnesses/etna/skills/documentation/templates/changelog-entry.md +62 -0
- package/data/harnesses/etna/skills/documentation/templates/changelog-index.md +41 -0
- package/data/harnesses/etna/skills/documentation/templates/docs-readme.md +70 -0
- package/data/harnesses/etna/skills/documentation/templates/domain-model.md +30 -0
- package/data/harnesses/etna/skills/documentation/templates/environment-registry.md +15 -0
- package/data/harnesses/etna/skills/documentation/templates/feature.md +149 -0
- package/data/harnesses/etna/skills/documentation/templates/glossary.md +11 -0
- package/data/harnesses/etna/skills/documentation/templates/memory-main.md +25 -0
- package/data/harnesses/etna/skills/documentation/templates/migration-runbook.md +34 -0
- package/data/harnesses/etna/skills/documentation/templates/non-goals.md +11 -0
- package/data/harnesses/etna/skills/documentation/templates/operations-procedure.md +36 -0
- package/data/harnesses/etna/skills/documentation/templates/plan.md +64 -0
- package/data/harnesses/etna/skills/documentation/templates/protected-files.md +37 -0
- package/data/harnesses/etna/skills/documentation/templates/root-readme.md +104 -0
- package/data/harnesses/etna/skills/documentation/templates/security-overview.md +27 -0
- package/data/harnesses/etna/skills/documentation/templates/structure.md +65 -0
- package/data/harnesses/etna/skills/documentation/templates/system-overview.md +32 -0
- package/data/harnesses/etna/skills/documentation/templates/testing-strategy.md +29 -0
- package/data/harnesses/etna/skills/workflow-mapper/SKILL.md +1 -1
- package/data/harnesses/hr/.prettierignore +6 -0
- package/data/harnesses/hr/CLAUDE.md +19 -23
- package/data/harnesses/hr/harness.json +2 -2
- package/data/harnesses/hr/skills/evaluator/SKILL.md +1 -1
- package/data/harnesses/hr/skills/interview-eval/SKILL.md +1 -1
- package/data/harnesses/kb-agi/.prettierignore +6 -0
- package/data/harnesses/kb-agi/CLAUDE.md +12 -12
- package/data/harnesses/kb-agi/harness.json +1 -1
- package/package.json +1 -1
- package/data/harnesses/code/skills/documentation/references/templates.md +0 -1091
- package/data/harnesses/etna/skills/documentation/references/templates.md +0 -1091
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# docs/README.md (Documentation Root)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the entry point for all documentation in a repo. Created during baseline audit.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
# {Project Name} Documentation
|
|
7
|
+
|
|
8
|
+
Technical documentation for {project description}.
|
|
9
|
+
|
|
10
|
+
> For documentation organization, authority map, and folder rules, see **[structure.md](structure.md)**.
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## Quick Links
|
|
15
|
+
|
|
16
|
+
| Document | Description |
|
|
17
|
+
| --------------------------------- | ------------------------------------ |
|
|
18
|
+
| [Structure](structure.md) | Documentation entry point and rules |
|
|
19
|
+
| [Setup](operations/setup.md) | Installation and configuration guide |
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Architecture
|
|
24
|
+
|
|
25
|
+
System design, steering docs, and standing decisions — the truth layer.
|
|
26
|
+
|
|
27
|
+
- [system-design.md](architecture/system-design.md) - System overview: subsystems and key flows
|
|
28
|
+
- [domain-model.md](architecture/domain-model.md) - Entities, relationships, state ownership
|
|
29
|
+
- [glossary.md](architecture/glossary.md) - Project vocabulary
|
|
30
|
+
- [non-goals.md](architecture/non-goals.md) - What this system deliberately does not do
|
|
31
|
+
- [decisions/](architecture/decisions/Readme.md) - Architecture Decisions (ADs)
|
|
32
|
+
{list other architecture docs — api.md, security.md — when present}
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Features
|
|
37
|
+
|
|
38
|
+
Living reference docs for implemented features (how things currently work).
|
|
39
|
+
|
|
40
|
+
- [feature-name.md](features/feature-name.md) - Feature description
|
|
41
|
+
{list all feature docs}
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## Operations
|
|
46
|
+
|
|
47
|
+
How to run, develop, and deploy.
|
|
48
|
+
|
|
49
|
+
- [setup.md](operations/setup.md) - Installation and configuration guide
|
|
50
|
+
{list all operations docs — environment.md when present}
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## History
|
|
55
|
+
|
|
56
|
+
The records — everything dated, frozen, or append-only.
|
|
57
|
+
|
|
58
|
+
- [CHANGELOG.md](history/CHANGELOG.md) - Master changelog index
|
|
59
|
+
- [changelog/](history/changelog/) - Individual changelog entries
|
|
60
|
+
- [plans/](history/plans/) - Implementation plans (frozen at completion)
|
|
61
|
+
- [migrations/](history/migrations/) - One-shot migration runbooks (frozen once executed)
|
|
62
|
+
- [research/](history/research/) - Deep-research artifacts (one folder per topic)
|
|
63
|
+
- [backlog.md](history/backlog.md) - Tracked work items and technical debt
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## Contributing
|
|
68
|
+
|
|
69
|
+
See [CLAUDE.md](../CLAUDE.md) for documentation guidelines.
|
|
70
|
+
```
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Domain Model (docs/architecture/domain-model.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the entities the system is about — what they are, how they relate, and who owns their state. The vocabulary here must match the glossary and the code; when they disagree, fix the disagreement, don't document around it.
|
|
4
|
+
|
|
5
|
+
Required: **Entities**, **Relationships**. Optional: Lifecycle states, Invariants.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# Domain Model
|
|
9
|
+
|
|
10
|
+
## Entities
|
|
11
|
+
|
|
12
|
+
| Entity | What it is | State lives in |
|
|
13
|
+
| ------ | ---------- | -------------- |
|
|
14
|
+
| {Entity} | {one line} | {table / slice / service} |
|
|
15
|
+
|
|
16
|
+
## Relationships
|
|
17
|
+
|
|
18
|
+
- {EntityA} 1—N {EntityB} — {the meaning of the link}
|
|
19
|
+
- {EntityB} N—N {EntityC} via {join} — {meaning}
|
|
20
|
+
|
|
21
|
+
## Lifecycle states
|
|
22
|
+
|
|
23
|
+
{Only for entities with real state machines.}
|
|
24
|
+
|
|
25
|
+
- **{Entity}**: draft → active → archived — {what moves it between states}
|
|
26
|
+
|
|
27
|
+
## Invariants
|
|
28
|
+
|
|
29
|
+
- {A relationship or state rule that must always hold, stated as a constraint}
|
|
30
|
+
```
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Environment Registry (docs/operations/environment.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the config surface — every variable the code reads, in one table. `.env.example` mirrors this doc's variable list.
|
|
4
|
+
|
|
5
|
+
**Placeholders only, never real values.** A real-looking password, account ID, or personal profile name in a doc is a leak, and one developer's local setup written as the canonical value is a trap for everyone else. Values in this doc are `{placeholder}` descriptions.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# Environment Registry
|
|
9
|
+
|
|
10
|
+
Every variable the code reads. `.env.example` mirrors this list.
|
|
11
|
+
|
|
12
|
+
| Variable | Purpose | Required | Where set | Secret |
|
|
13
|
+
| -------- | ------- | -------- | --------- | ------ |
|
|
14
|
+
| `DATABASE_URL` | {one line} | yes / default: `{value}` | local `.env` / CI / prod | yes |
|
|
15
|
+
```
|
|
@@ -0,0 +1,149 @@
|
|
|
1
|
+
# Feature Documentation — the LLD (docs/features/{feature}.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: every feature in `docs/features/`. The feature doc is the feature's **LLD (low-level design)**: the same file persists from design (Status: Draft, written in LLD Mode) through implementation to live reference (Status: Active). Sections fill in as the feature matures — no template swap. The body always describes the feature as it currently is; the journey lives in the linked plan and changelog entries.
|
|
4
|
+
|
|
5
|
+
**Required vs optional.** Required in every feature doc: the frontmatter, **Goal**, and **Background** — plus **Files** once implementation exists (a Draft for unbuilt code has no real paths to list) and **Current Behavior** once research or implementation exists (at Draft it's the pre-feature baseline; at Active it's how the feature works today). Every other section is optional: include it only when the feature has something real to put in it (no Redux → no Redux section; no risks worth naming → no Risks section). A **minimal form** is sanctioned for small features: frontmatter + Goal + a short how-it-works section + Files. A two-screen doc that is accurate beats a full-template doc with empty sections.
|
|
6
|
+
|
|
7
|
+
The four research-derived sections (**Affected Modules**, **Conventions to Follow**, **Current Behavior**, **Ownership Conflicts**) map 1:1 to the `lld-mode` agent's return shape. The orchestrator drops its findings into those slots without restructuring.
|
|
8
|
+
|
|
9
|
+
```yaml
|
|
10
|
+
---
|
|
11
|
+
owns: ["src/feature/**", "src/other/file.ts"] # required — code-path globs this doc owns (the only ownership key)
|
|
12
|
+
module: billing # optional — single bounded-context label; omit if cross-cutting
|
|
13
|
+
keywords: [invoice, pdf] # required — discovery terms
|
|
14
|
+
status: active # required — active | draft | deprecated
|
|
15
|
+
last-reviewed: YYYY-MM-DD # optional tooling key — stamped on substantive review/update; the maintenance agent ranks audit priority by it (metadata, never narrated in the body)
|
|
16
|
+
---
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
> Declare the code paths it owns in its `owns:` frontmatter — projected at Draft, confirmed against real code at Active.
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
# {Feature Name}
|
|
23
|
+
|
|
24
|
+
<!-- Lifecycle lives in the frontmatter `status:` key (active | draft | deprecated) — the single source of truth. Don't restate it in the body. -->
|
|
25
|
+
**Plan:** [history/plans/YYYY-MM-DD-feature-name.md](../history/plans/YYYY-MM-DD-feature-name.md) <!-- added once a plan exists -->
|
|
26
|
+
|
|
27
|
+
## Goal
|
|
28
|
+
|
|
29
|
+
One sentence. What this feature accomplishes, in user-facing terms.
|
|
30
|
+
|
|
31
|
+
## Goals & Non-Goals
|
|
32
|
+
|
|
33
|
+
**In scope**
|
|
34
|
+
- Bullet 1
|
|
35
|
+
- Bullet 2
|
|
36
|
+
|
|
37
|
+
**Out of scope**
|
|
38
|
+
- Bullet 1
|
|
39
|
+
|
|
40
|
+
## Background
|
|
41
|
+
|
|
42
|
+
Why this feature exists. The user need, the business trigger, the constraint that pushed it above the line. One paragraph.
|
|
43
|
+
|
|
44
|
+
(For Product-level work, also include: problem statement, key hypotheses, open questions.)
|
|
45
|
+
|
|
46
|
+
## Approach
|
|
47
|
+
|
|
48
|
+
High-level shape of the solution. ASCII diagram if it helps. Implementation specifics belong in the plan.
|
|
49
|
+
|
|
50
|
+
## Affected Modules
|
|
51
|
+
|
|
52
|
+
(From lld-mode research) Files, routes, components, slices this feature involves. Group by module.
|
|
53
|
+
|
|
54
|
+
| Module | Path | Role in this feature |
|
|
55
|
+
|--------|------|----------------------|
|
|
56
|
+
|
|
57
|
+
## Conventions to Follow
|
|
58
|
+
|
|
59
|
+
(From lld-mode research) Naming patterns, structural patterns, doc-fit heuristics confirmed for the area being touched. Cite the source file(s) where the convention is established.
|
|
60
|
+
|
|
61
|
+
## Current Behavior
|
|
62
|
+
|
|
63
|
+
(From lld-mode research) How the relevant part of the system works *today*, before this feature lands. Without this baseline the design intent is hard to evaluate.
|
|
64
|
+
|
|
65
|
+
## Ownership Conflicts
|
|
66
|
+
|
|
67
|
+
(From lld-mode research) Existing feature docs whose `owns:` globs overlap with the projected scope. Resolve before the plan starts — leave nothing unresolved.
|
|
68
|
+
|
|
69
|
+
| Conflicting doc | Overlapping path(s) | Resolution |
|
|
70
|
+
|-----------------|---------------------|------------|
|
|
71
|
+
|
|
72
|
+
## Architecture
|
|
73
|
+
|
|
74
|
+
[ASCII diagram. Fill once implementation lands. See style-guide.md for box-drawing patterns.]
|
|
75
|
+
|
|
76
|
+
## Key Functions
|
|
77
|
+
|
|
78
|
+
### `functionName(param1, param2)`
|
|
79
|
+
**Goal:** What it accomplishes
|
|
80
|
+
**Input:**
|
|
81
|
+
- `param1` (type) - Description
|
|
82
|
+
- `param2` (type) - Description
|
|
83
|
+
**Output:** Return type and shape
|
|
84
|
+
**Side Effects:** DB writes, API calls, state updates
|
|
85
|
+
|
|
86
|
+
### `hookName(config)`
|
|
87
|
+
**Goal:** What it provides
|
|
88
|
+
**Returns:** `{ data, loading, error }`
|
|
89
|
+
**Triggers:** On mount, on change, manual
|
|
90
|
+
|
|
91
|
+
## State
|
|
92
|
+
|
|
93
|
+
**Frontend (at persistence):**
|
|
94
|
+
{
|
|
95
|
+
"data": [],
|
|
96
|
+
"changes": { "added": [], "updated": [], "removed": [] }
|
|
97
|
+
// "cache": {} // UNUSED: dead key; kept so old persisted state rehydrates
|
|
98
|
+
}
|
|
99
|
+
|
|
100
|
+
**Storage:** localStorage `app_state`
|
|
101
|
+
|
|
102
|
+
**Backend:**
|
|
103
|
+
export const resources = pgTable('resources', {
|
|
104
|
+
id: text('id').primaryKey(),
|
|
105
|
+
data: jsonb('data'),
|
|
106
|
+
// oldField: text('old_field'), // UNUSED: dead column; nothing reads it
|
|
107
|
+
});
|
|
108
|
+
|
|
109
|
+
**API Shape:**
|
|
110
|
+
{ "status": 1, "data": {...} }
|
|
111
|
+
|
|
112
|
+
## Redux (if applicable)
|
|
113
|
+
|
|
114
|
+
**Slice:** `sliceName`
|
|
115
|
+
|
|
116
|
+
**Actions:**
|
|
117
|
+
- `setData(payload)` - Replace all data
|
|
118
|
+
- `upsertItem(item)` - Add or update single item
|
|
119
|
+
|
|
120
|
+
**Selectors:**
|
|
121
|
+
- `selectAll(state)` → `Array<Item>`
|
|
122
|
+
- `selectById(state, id)` → `Item | undefined`
|
|
123
|
+
|
|
124
|
+
## Files
|
|
125
|
+
|
|
126
|
+
- `src/path/to/main.js` - Core logic
|
|
127
|
+
- `src/path/to/hooks.js` - React hooks
|
|
128
|
+
|
|
129
|
+
## Open Questions
|
|
130
|
+
|
|
131
|
+
- Question — who decides, by when
|
|
132
|
+
- (Resolved questions: fold the resolution into Background.)
|
|
133
|
+
|
|
134
|
+
## Risks
|
|
135
|
+
|
|
136
|
+
- Risk — likelihood / impact / mitigation
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
### Section evolution
|
|
140
|
+
|
|
141
|
+
Sections fill in across the feature's lifecycle. No template swap — they accumulate in place.
|
|
142
|
+
|
|
143
|
+
| When | Sections written | Source |
|
|
144
|
+
| --- | --- | --- |
|
|
145
|
+
| Status: Draft (design) | Goal, Goals & Non-Goals, Background, Approach, Open Questions, Risks | User interview |
|
|
146
|
+
| Status: Draft (research) | Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts | lld-mode agent |
|
|
147
|
+
| Status: Draft → Active (implementation lands) | Architecture, Key Functions, State, Redux, Files; `owns:` globs confirmed against real code | Main agent (from actual code) |
|
|
148
|
+
|
|
149
|
+
Resolved Open Questions can be summarized into Background; unresolved ones stay visible.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Glossary (docs/architecture/glossary.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the project's vocabulary — one name per concept, one line per name. Alphabetical. When the code uses a different name than the docs, record it in **In code** so readers can bridge; one concept never gets two doc names.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
# Glossary
|
|
7
|
+
|
|
8
|
+
| Term | Meaning | In code |
|
|
9
|
+
| ---- | ------- | ------- |
|
|
10
|
+
| {Term} | {one-line definition} | `{identifier}` |
|
|
11
|
+
```
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Scaffold: docs/memory/main.md
|
|
2
|
+
|
|
3
|
+
Baseline scaffold — created if missing (the `maintenance` agent's baseline calls this). Target file: `docs/memory/main.md`.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
---
|
|
7
|
+
type: project-memory
|
|
8
|
+
owner: main-agent
|
|
9
|
+
description: Project-wide patterns and conventions confirmed in this codebase. Project facts only — user-centric facts go in ~/.claude/.
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Main Agent — Project Memory
|
|
13
|
+
|
|
14
|
+
Append entries below, oldest at bottom. Format:
|
|
15
|
+
|
|
16
|
+
## YYYY-MM-DD — {topic}
|
|
17
|
+
|
|
18
|
+
{1-3 line fact, with file paths or references where relevant}
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## {today} — Baseline
|
|
23
|
+
|
|
24
|
+
Memory file initialized during documentation baseline (structure v{harness-version} — read from `.claude/harness.json` / `docs/structure.md` frontmatter; never hardcode a literal version).
|
|
25
|
+
```
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Migration Runbook (docs/history/migrations/YYYY-MM-DD-{slug}.md)
|
|
2
|
+
|
|
3
|
+
Record. Use for: a **one-shot** migration, upgrade, or data operation — authored before execution, executed once, then outcome-stamped and frozen. Supporting scripts live beside it in a same-named folder when needed (`YYYY-MM-DD-{slug}/`).
|
|
4
|
+
|
|
5
|
+
Required: **Goal**, **Steps**, **Verification**, and — after execution — the **Outcome** stamp. Optional: Preconditions, Rollback.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# Migration: {Title}
|
|
9
|
+
|
|
10
|
+
**Goal:** What this migration accomplishes and why it runs now, one or two lines.
|
|
11
|
+
**Executes against:** {environment / database / system}
|
|
12
|
+
|
|
13
|
+
## Preconditions
|
|
14
|
+
|
|
15
|
+
- Backups taken, feature flags set, access confirmed — exact checks
|
|
16
|
+
|
|
17
|
+
## Steps
|
|
18
|
+
|
|
19
|
+
1. One action per step, exact command in a code block
|
|
20
|
+
2. Note expected output where it disambiguates success from failure
|
|
21
|
+
|
|
22
|
+
## Verification
|
|
23
|
+
|
|
24
|
+
- The observable end state that confirms success — exact check commands
|
|
25
|
+
|
|
26
|
+
## Rollback
|
|
27
|
+
|
|
28
|
+
- How to undo, and the point of no return
|
|
29
|
+
|
|
30
|
+
## Outcome
|
|
31
|
+
|
|
32
|
+
<!-- Stamped once, immediately after execution; the file freezes with it. -->
|
|
33
|
+
**Executed:** YYYY-MM-DD — {result: clean | issues encountered + how resolved | aborted + why}
|
|
34
|
+
```
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Non-Goals (docs/architecture/non-goals.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: what the system deliberately does **not** do. A non-goal is a decision, not an omission — each entry carries the why and what would reopen it. Readers (and agents) use this to stop re-proposing settled exclusions.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
# Non-Goals
|
|
7
|
+
|
|
8
|
+
Things this system deliberately does not do. Each is a decision — don't re-propose one without new information of the kind its "revisit if" names.
|
|
9
|
+
|
|
10
|
+
- **{Non-goal}** — {why it's excluded}. Revisit if: {the trigger that would reopen it}.
|
|
11
|
+
```
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# Operations Procedure (docs/operations/{procedure}.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: any **recurring** procedure — setup, development, deployment, maintenance. A procedure is consulted mid-task, not read: exact commands, copy-paste runnable, no narrative. Updated in place whenever the workflow changes.
|
|
4
|
+
|
|
5
|
+
A **one-shot** procedure (a migration, an upgrade, an incident response executed once) is not an operations doc — it is a **Migration Runbook** (record, below). The test: will someone run this again next month? Yes → operations. No → runbook.
|
|
6
|
+
|
|
7
|
+
Required: **Goal**, **Steps**, **Verification**. Optional: Preconditions, Troubleshooting, Rollback — include only when they carry real content.
|
|
8
|
+
|
|
9
|
+
If a procedure is a deterministic command list run frequently, script it and have the doc point at the script — a doc should carry judgment (when, why, what to check), not replace automation.
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
# {Procedure Name}
|
|
13
|
+
|
|
14
|
+
**Goal:** What this procedure accomplishes, one line.
|
|
15
|
+
|
|
16
|
+
## Preconditions
|
|
17
|
+
|
|
18
|
+
- Access, tools, or state required before starting — exact versions, env vars, credentials location
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
1. One action per step, exact command in a code block
|
|
23
|
+
2. Note expected output where it disambiguates success from failure
|
|
24
|
+
|
|
25
|
+
## Verification
|
|
26
|
+
|
|
27
|
+
- The observable end state that confirms it worked — exact check commands, not "it should work now"
|
|
28
|
+
|
|
29
|
+
## Troubleshooting
|
|
30
|
+
|
|
31
|
+
- Symptom → cause → fix (append entries as failures are root-caused)
|
|
32
|
+
|
|
33
|
+
## Rollback
|
|
34
|
+
|
|
35
|
+
- How to undo, and when undo stops being possible
|
|
36
|
+
```
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
# Plan (docs/history/plans/YYYY-MM-DD-feature-name.md)
|
|
2
|
+
|
|
3
|
+
Record. Use for: every implementation plan. Plans are created here directly with `Status: Draft`, flip to `Status: In Progress` when work starts, and freeze at `Status: Complete` or `Status: Abandoned`. Once frozen, never edit — write a new dated plan if scope changes. The plan records the journey; the truth it implemented lives on in the feature doc and any AD it touched.
|
|
4
|
+
|
|
5
|
+
The `boundary` skill parses the **Proposed Changes** sections to check boundary impact before execution. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# {Feature Name}
|
|
9
|
+
|
|
10
|
+
**Status:** Draft | In Progress | Complete | Abandoned
|
|
11
|
+
**Spec:** [docs/features/{feature}.md](../../features/{feature}.md)
|
|
12
|
+
**Started:** YYYY-MM-DD
|
|
13
|
+
**Completed:** YYYY-MM-DD <!-- fill when status flips to Complete -->
|
|
14
|
+
|
|
15
|
+
## Background
|
|
16
|
+
|
|
17
|
+
Why this work is happening *now*. Link to the spec for *what* we're building; this section is the motivation and the trigger. One paragraph.
|
|
18
|
+
|
|
19
|
+
## Proposed Changes
|
|
20
|
+
|
|
21
|
+
### New Files
|
|
22
|
+
|
|
23
|
+
- `src/path/new-file.js` — purpose
|
|
24
|
+
|
|
25
|
+
### Modified Files
|
|
26
|
+
|
|
27
|
+
- `src/path/existing.js` — what changes and why
|
|
28
|
+
|
|
29
|
+
### New Entities / State
|
|
30
|
+
|
|
31
|
+
- `entities.foo` — new Redux slice / DB table / persisted shape
|
|
32
|
+
- Persisted state addition: `state.bar.baz` (default `null` for existing users on rehydrate)
|
|
33
|
+
|
|
34
|
+
### API Changes
|
|
35
|
+
|
|
36
|
+
- `POST /api/foo` — new route, request `{...}`, response `{status, data}`
|
|
37
|
+
- `PUT /api/bar` — request shape changes; see Migration
|
|
38
|
+
|
|
39
|
+
### Cross-Module Contracts Affected
|
|
40
|
+
|
|
41
|
+
- List which cross-cutting contracts this plan affects (db schema, wire envelope, auth, events, env/config, …)
|
|
42
|
+
- "None" is a valid answer and means the `boundary` check will pass cleanly
|
|
43
|
+
|
|
44
|
+
## Implementation Steps
|
|
45
|
+
|
|
46
|
+
1. Concrete, ordered, testable
|
|
47
|
+
2. Each step ends with something verifiable
|
|
48
|
+
3. ...
|
|
49
|
+
|
|
50
|
+
## Done Criteria
|
|
51
|
+
|
|
52
|
+
- [ ] Implementation complete and verified
|
|
53
|
+
- [ ] Affected docs updated (use the injected ownership index to find them)
|
|
54
|
+
- [ ] Changelog entry created in `docs/history/changelog/`
|
|
55
|
+
- [ ] Plan marked `Status: Complete`, **Completed:** date filled
|
|
56
|
+
|
|
57
|
+
## Open Questions
|
|
58
|
+
|
|
59
|
+
- Question — who decides, by when
|
|
60
|
+
|
|
61
|
+
## Risks
|
|
62
|
+
|
|
63
|
+
- Risk — likelihood / impact / mitigation
|
|
64
|
+
```
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Protected Files
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: documenting critical files that need approval before modification.
|
|
4
|
+
|
|
5
|
+
This doc answers *what is protected and why breaking it hurts* — nothing more. Don't duplicate function-level detail here (signatures, inputs/outputs): it drifts from both the code and the owning feature doc. The owning feature doc is the canonical reference for how the code works; link to it.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# Protected Files
|
|
9
|
+
|
|
10
|
+
Critical files requiring approval before modification.
|
|
11
|
+
|
|
12
|
+
## File List
|
|
13
|
+
|
|
14
|
+
# Category 1 - Description
|
|
15
|
+
path/to/critical/file1.js
|
|
16
|
+
path/to/critical/file2.js
|
|
17
|
+
|
|
18
|
+
# Category 2 - Description
|
|
19
|
+
path/to/another/file.js
|
|
20
|
+
|
|
21
|
+
## Risk Summary
|
|
22
|
+
|
|
23
|
+
| Category | Risk if Broken |
|
|
24
|
+
|------------|-----------------|
|
|
25
|
+
| Category 1 | Specific impact |
|
|
26
|
+
| Category 2 | Specific impact |
|
|
27
|
+
|
|
28
|
+
## Why Protected
|
|
29
|
+
|
|
30
|
+
### Category 1: [Name]
|
|
31
|
+
|
|
32
|
+
**Purpose:** What these files do, one or two lines
|
|
33
|
+
**Owning doc:** [docs/features/{feature}.md] — canonical reference for how this code works
|
|
34
|
+
**Invariants:**
|
|
35
|
+
- The behavior that must not break, stated as a constraint (not a function tour)
|
|
36
|
+
- Important point 2
|
|
37
|
+
```
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Project Root README
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the human-facing entry point at the repository root (`/README.md`) — what visitors and new contributors land on. Distinct from `docs/README.md` (the agent/doc index — see **docs/README.md (Documentation Root)** above). The two coexist; don't merge them.
|
|
4
|
+
|
|
5
|
+
### Strategy
|
|
6
|
+
|
|
7
|
+
The root README answers, in order:
|
|
8
|
+
|
|
9
|
+
1. **What is this?** — one to two sentences, no marketing claims
|
|
10
|
+
2. **What do I get if I install it?** — capability families
|
|
11
|
+
3. **What's it built on?** — terse stack list with versions
|
|
12
|
+
4. **How do I run it?** — the three or four scripts that matter
|
|
13
|
+
5. **How is it laid out?** — directory tree, one-liner per significant folder
|
|
14
|
+
6. **How do I extend it?** — numbered contribution checklist
|
|
15
|
+
7. **What state is it in?** — pre-publish, beta, stable, internal
|
|
16
|
+
|
|
17
|
+
Skip any section that doesn't apply. Don't pad to fill the template.
|
|
18
|
+
|
|
19
|
+
### Writing rules
|
|
20
|
+
|
|
21
|
+
- **Sentence-case headings.** "Getting started", not "Getting Started".
|
|
22
|
+
- **Concrete over abstract.** Real versions, real paths, real commands. No "leverages cutting-edge…".
|
|
23
|
+
- **The tagline answers "what is this?"** — not "why is it great?". Two sentences max.
|
|
24
|
+
- **Tables for enumeration** (routes, commands, endpoints). **Bullets for families and categories.**
|
|
25
|
+
- **Directory tree as a code block**, not a nested markdown list.
|
|
26
|
+
- **Numbered checklist** for "how to add a thing" — readers should be able to follow it top-to-bottom without re-reading.
|
|
27
|
+
- **Point to `docs/` for depth.** The root README links into deep docs; it doesn't host them.
|
|
28
|
+
- **Detect the package manager from the lockfile** (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise npm) and write commands accordingly. Don't hardcode `npm` if the repo uses pnpm.
|
|
29
|
+
|
|
30
|
+
### Template
|
|
31
|
+
|
|
32
|
+
```markdown
|
|
33
|
+
# {package-name}
|
|
34
|
+
|
|
35
|
+
{One- to two-sentence positioning. What it is and what scope it covers. No superlatives, no value claims.}
|
|
36
|
+
|
|
37
|
+
## What's in the box
|
|
38
|
+
|
|
39
|
+
- **{Family 1}** — {what's in it; a few specific items, comma-listed.}
|
|
40
|
+
- **{Family 2}** — {what's in it.}
|
|
41
|
+
- **{Family 3}** — {what's in it.}
|
|
42
|
+
|
|
43
|
+
The full surface lives in [`{path/to/public-index}`]({path/to/public-index}). ← optional pointer for libraries
|
|
44
|
+
|
|
45
|
+
## Stack
|
|
46
|
+
|
|
47
|
+
- {Framework} {version} · {Language} {version}
|
|
48
|
+
- {Build tool} {version}
|
|
49
|
+
- {Other load-bearing deps}
|
|
50
|
+
|
|
51
|
+
## Getting started
|
|
52
|
+
|
|
53
|
+
\`\`\`bash
|
|
54
|
+
{pm} install
|
|
55
|
+
{pm} run dev # what it does (port, URL)
|
|
56
|
+
{pm} run build # what it does
|
|
57
|
+
{pm} run preview # what it does (omit if not applicable)
|
|
58
|
+
\`\`\`
|
|
59
|
+
|
|
60
|
+
{Optional one-liner about first-run behavior — e.g., "Dev server lands on /playground."}
|
|
61
|
+
|
|
62
|
+
## {Runtime entry point} ← optional; e.g., "The playground", "CLI", "API endpoints"
|
|
63
|
+
|
|
64
|
+
{Brief description of the dev/runtime surface.}
|
|
65
|
+
|
|
66
|
+
| {Thing} | {What it shows / does} |
|
|
67
|
+
| -------------------- | ---------------------- |
|
|
68
|
+
| `{route or command}` | {description} |
|
|
69
|
+
|
|
70
|
+
## Layout
|
|
71
|
+
|
|
72
|
+
\`\`\`
|
|
73
|
+
src/
|
|
74
|
+
├── {entry-file} # {purpose}
|
|
75
|
+
├── {folder}/ # {purpose}
|
|
76
|
+
│ └── ...
|
|
77
|
+
└── {folder}/ # {purpose}
|
|
78
|
+
\`\`\`
|
|
79
|
+
|
|
80
|
+
## Adding a {primary unit}
|
|
81
|
+
|
|
82
|
+
1. {Drop the source under the right family/folder.}
|
|
83
|
+
2. {Re-export from the public surface.}
|
|
84
|
+
3. {Wire into the playground / example app / test harness so reviewers can see it render.}
|
|
85
|
+
4. {Document any divergence from upstream in `docs/{...}`.}
|
|
86
|
+
|
|
87
|
+
## Styling ← optional; replace with whichever cross-cutting concern matters most
|
|
88
|
+
|
|
89
|
+
{Configuration notes that affect every consumer — design tokens, conventions, opt-outs.}
|
|
90
|
+
|
|
91
|
+
## Status
|
|
92
|
+
|
|
93
|
+
{Pre-publish, beta, stable, internal-only. State the stability tier per surface — which APIs are contracts and which are experimental — so readers know what can be relied on.}
|
|
94
|
+
|
|
95
|
+
## License
|
|
96
|
+
|
|
97
|
+
{License name — scope. e.g., "UNLICENSED — internal use only", "MIT".}
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### Baseline scaffolding behavior
|
|
101
|
+
|
|
102
|
+
The baseline audit **does** scaffold the project root README when missing. The risk this template guards against — template-shaped placeholders that look abandoned — is mitigated by the writing rules above: fill every section with concrete details from the repo (real package manager from the lockfile, real scripts, real layout, real status). Skip sections that genuinely don't apply rather than leaving stubs.
|
|
103
|
+
|
|
104
|
+
**Never overwrite an existing root README** during a baseline. If one is present — even sparse or outdated — leave it untouched. Treat updates to a pre-existing root README as a separate, explicit request.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Security Overview (docs/architecture/security.md)
|
|
2
|
+
|
|
3
|
+
Truth document. Use for: the single place the system's security posture is stated — assets, trust boundaries, controls, and accepted risks. Controls link to the code that implements them; this doc asserts, the code proves.
|
|
4
|
+
|
|
5
|
+
Required: **Trust boundaries**, **Controls**. Optional: Assets, Accepted risks.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
# Security Overview
|
|
9
|
+
|
|
10
|
+
## Assets
|
|
11
|
+
|
|
12
|
+
- {What's worth protecting — data classes, credentials, tenant isolation}
|
|
13
|
+
|
|
14
|
+
## Trust boundaries
|
|
15
|
+
|
|
16
|
+
- {Boundary} — {what crosses it, and what checks the crossing}
|
|
17
|
+
|
|
18
|
+
## Controls
|
|
19
|
+
|
|
20
|
+
| Control | Protects against | Implemented in |
|
|
21
|
+
| ------- | ---------------- | -------------- |
|
|
22
|
+
| {control} | {threat} | `{file/module}` |
|
|
23
|
+
|
|
24
|
+
## Accepted risks
|
|
25
|
+
|
|
26
|
+
- {Risk knowingly carried} — accepted because {reason}; owner: {who}. Revisit if: {trigger}.
|
|
27
|
+
```
|