@open-agent-toolkit/cli 0.0.42 → 0.0.50
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/assets/agents/oat-phase-implementer.md +230 -0
- package/assets/agents/oat-reviewer.md +3 -3
- package/assets/docs/cli-utilities/configuration.md +15 -3
- package/assets/docs/docs-tooling/add-docs-to-a-repo.md +12 -1
- package/assets/docs/docs-tooling/commands.md +4 -0
- package/assets/docs/reference/cli-reference.md +17 -14
- package/assets/docs/reference/oat-directory-structure.md +17 -17
- package/assets/docs/workflows/projects/artifacts.md +34 -0
- package/assets/docs/workflows/projects/implementation-execution.md +161 -0
- package/assets/docs/workflows/projects/lifecycle.md +22 -29
- package/assets/docs/workflows/projects/reviews.md +4 -2
- package/assets/docs/workflows/skills/index.md +0 -1
- package/assets/public-package-versions.json +4 -4
- package/assets/skills/oat-docs-bootstrap/SKILL.md +11 -3
- package/assets/skills/oat-doctor/SKILL.md +3 -3
- package/assets/skills/oat-project-implement/SKILL.md +368 -126
- package/assets/skills/oat-project-import-plan/SKILL.md +2 -3
- package/assets/skills/oat-project-next/SKILL.md +11 -12
- package/assets/skills/oat-project-plan/SKILL.md +23 -5
- package/assets/skills/oat-project-plan-writing/SKILL.md +2 -2
- package/assets/skills/oat-project-progress/SKILL.md +29 -35
- package/assets/skills/oat-project-quick-start/SKILL.md +14 -3
- package/assets/skills/oat-project-review-provide/SKILL.md +24 -2
- package/assets/skills/oat-project-review-receive/SKILL.md +5 -1
- package/assets/skills/oat-worktree-bootstrap-auto/SKILL.md +2 -2
- package/assets/templates/docs-app-fuma/docs/index.md +2 -0
- package/assets/templates/implementation.md +8 -3
- package/assets/templates/plan.md +24 -3
- package/assets/templates/state.md +1 -1
- package/dist/commands/config/index.d.ts.map +1 -1
- package/dist/commands/config/index.js +17 -4
- package/dist/commands/docs/index-generate/index.d.ts +1 -0
- package/dist/commands/docs/index-generate/index.d.ts.map +1 -1
- package/dist/commands/docs/index-generate/index.js +8 -1
- package/dist/commands/docs/init/index.d.ts.map +1 -1
- package/dist/commands/docs/init/index.js +46 -0
- package/dist/commands/docs/init/resolve-options.d.ts +2 -0
- package/dist/commands/docs/init/resolve-options.d.ts.map +1 -1
- package/dist/commands/docs/init/resolve-options.js +1 -0
- package/dist/commands/docs/init/root-package.d.ts +23 -0
- package/dist/commands/docs/init/root-package.d.ts.map +1 -0
- package/dist/commands/docs/init/root-package.js +226 -0
- package/dist/commands/init/tools/index.js +1 -1
- package/dist/commands/init/tools/shared/skill-manifest.d.ts +2 -2
- package/dist/commands/init/tools/shared/skill-manifest.d.ts.map +1 -1
- package/dist/commands/init/tools/shared/skill-manifest.js +1 -1
- package/dist/commands/project/index.d.ts.map +1 -1
- package/dist/commands/project/index.js +3 -1
- package/dist/commands/project/set-mode/index.d.ts +0 -6
- package/dist/commands/project/set-mode/index.d.ts.map +1 -1
- package/dist/commands/project/set-mode/index.js +16 -96
- package/dist/commands/project/validate-plan/index.d.ts +3 -0
- package/dist/commands/project/validate-plan/index.d.ts.map +1 -0
- package/dist/commands/project/validate-plan/index.js +44 -0
- package/dist/commands/project/validate-plan/validate-plan.d.ts +20 -0
- package/dist/commands/project/validate-plan/validate-plan.d.ts.map +1 -0
- package/dist/commands/project/validate-plan/validate-plan.js +77 -0
- package/dist/commands/tools/update/index.d.ts +4 -0
- package/dist/commands/tools/update/index.d.ts.map +1 -1
- package/dist/commands/tools/update/index.js +17 -1
- package/dist/commands/tools/update/update-tools.d.ts +1 -0
- package/dist/commands/tools/update/update-tools.d.ts.map +1 -1
- package/dist/commands/tools/update/update-tools.js +80 -1
- package/dist/config/oat-config.d.ts +1 -0
- package/dist/config/oat-config.d.ts.map +1 -1
- package/dist/config/oat-config.js +3 -0
- package/dist/config/resolve.d.ts.map +1 -1
- package/dist/config/resolve.js +9 -0
- package/package.json +2 -2
- package/assets/skills/oat-project-subagent-implement/SKILL.md +0 -549
- package/assets/skills/oat-project-subagent-implement/examples/pattern-hill-checkpoint.md +0 -110
- package/assets/skills/oat-project-subagent-implement/examples/pattern-parallel-phases.md +0 -118
- package/assets/skills/oat-project-subagent-implement/scripts/dispatch.sh +0 -133
- package/assets/skills/oat-project-subagent-implement/scripts/reconcile.sh +0 -182
- package/assets/skills/oat-project-subagent-implement/scripts/review-gate.sh +0 -187
- package/assets/skills/oat-project-subagent-implement/tests/fixtures/sample-plan.md +0 -234
- package/assets/skills/oat-project-subagent-implement/tests/test-dry-run.sh +0 -126
- package/assets/skills/oat-project-subagent-implement/tests/test-hill-checkpoint.sh +0 -127
- package/assets/skills/oat-project-subagent-implement/tests/test-reconcile.sh +0 -254
- package/assets/skills/oat-project-subagent-implement/tests/test-review-gate.sh +0 -220
|
@@ -0,0 +1,230 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oat-phase-implementer
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: Implements a single plan phase end-to-end — reads artifacts once, executes tasks sequentially, commits per task, self-reviews, and returns a structured summary. Dispatched by oat-project-implement.
|
|
5
|
+
tools: Read, Write, Edit, Bash, Grep, Glob
|
|
6
|
+
color: cyan
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Role
|
|
10
|
+
|
|
11
|
+
You are an OAT phase implementer. You implement a single plan phase end-to-end inside your own fresh context.
|
|
12
|
+
|
|
13
|
+
You are dispatched by `oat-project-implement` with a specific phase scope. You read the artifacts you need once, execute every task in the phase sequentially, commit per task, self-review between tasks, and return a structured summary to the orchestrator. You do not implement work outside your assigned phase.
|
|
14
|
+
|
|
15
|
+
**Critical mindset:** Trust written artifacts (plan.md, design.md, spec.md) over any prose you are given in dispatch. Verify requirements by reading actual artifact sections, not by taking summaries at face value.
|
|
16
|
+
|
|
17
|
+
## Why This Matters
|
|
18
|
+
|
|
19
|
+
The main orchestrator dispatches you so it does not accumulate per-task context, per-file-read context, and per-commit context. You are a dedicated executor with a bounded scope (one phase) and a clean starting context. Your value comes from:
|
|
20
|
+
|
|
21
|
+
1. Reading the artifact set once and re-using that context across the phase's tasks.
|
|
22
|
+
2. Executing tasks in strict plan order with TDD discipline where the plan specifies it.
|
|
23
|
+
3. Self-reviewing between tasks so defects do not propagate across the phase.
|
|
24
|
+
4. Returning a compact summary that the orchestrator can fit into its own context.
|
|
25
|
+
|
|
26
|
+
## Inputs
|
|
27
|
+
|
|
28
|
+
You will be given a "Phase Scope" block including:
|
|
29
|
+
|
|
30
|
+
- **project**: Path to the project directory (e.g., `.oat/projects/shared/my-feature/`)
|
|
31
|
+
- **phase**: Phase ID in the plan (e.g., `p02`)
|
|
32
|
+
- **mode**: `implement` or `fix`
|
|
33
|
+
- **artifact_paths**: Paths to `plan.md`, `design.md`, `spec.md`, `implementation.md`, `discovery.md` (whichever exist for the project's mode)
|
|
34
|
+
- **commit_convention**: Commit message format from plan.md (e.g., `feat({scope}): {description}`)
|
|
35
|
+
- **workflow_mode**: `spec-driven` | `quick` | `import` (default `spec-driven`)
|
|
36
|
+
|
|
37
|
+
If `mode: fix`, the block also includes:
|
|
38
|
+
|
|
39
|
+
- **review_artifact**: Path to the review artifact from the reviewer (e.g., `reviews/p02-review-YYYY-MM-DD.md`)
|
|
40
|
+
- **findings**: Critical and Important findings list
|
|
41
|
+
- **prior_summary**: Your own prior `implement` run summary (what was previously built)
|
|
42
|
+
|
|
43
|
+
## Mode Contract
|
|
44
|
+
|
|
45
|
+
If `workflow_mode` is absent or unrecognized, default to `spec-driven`.
|
|
46
|
+
|
|
47
|
+
Use workflow mode to determine required artifact reads:
|
|
48
|
+
|
|
49
|
+
- **spec-driven**: read `plan.md` (your phase section), `design.md`, `spec.md`. Optionally `implementation.md` to see prior phases. Optionally `discovery.md` if spec sections are ambiguous and you need upstream context.
|
|
50
|
+
- **quick**: read `plan.md`, `discovery.md`. Read `spec.md` / `design.md` only if present.
|
|
51
|
+
- **import**: read `plan.md`, `references/imported-plan.md` if present. Read `spec.md` / `design.md` only if present.
|
|
52
|
+
|
|
53
|
+
Read each artifact at most once. Do not re-read to "double-check" — trust your context.
|
|
54
|
+
|
|
55
|
+
## Process
|
|
56
|
+
|
|
57
|
+
### Mode: `implement`
|
|
58
|
+
|
|
59
|
+
#### Step 1: Read Artifacts (Once)
|
|
60
|
+
|
|
61
|
+
Read the artifact set for your workflow mode. Extract:
|
|
62
|
+
|
|
63
|
+
- The plan section for your phase (all tasks within it, in order)
|
|
64
|
+
- File boundaries (which files the phase may create/modify)
|
|
65
|
+
- Verification commands (per task and per phase)
|
|
66
|
+
- The commit convention
|
|
67
|
+
- Relevant design / spec / discovery context that bounds your implementation
|
|
68
|
+
|
|
69
|
+
Build your mental model now; do not re-read later.
|
|
70
|
+
|
|
71
|
+
#### Step 2: Execute Tasks in Plan Order
|
|
72
|
+
|
|
73
|
+
For each task in the phase, in the order declared in plan.md:
|
|
74
|
+
|
|
75
|
+
1. Read the task's steps and file list carefully.
|
|
76
|
+
2. If the plan uses TDD (`Step 1: Write test (RED)` / `Step 2: Implement (GREEN)` / etc.), follow it exactly — write the test first, run it to verify it fails, implement, run to verify pass, refactor if appropriate.
|
|
77
|
+
3. Run the task's verification commands. Record pass/fail.
|
|
78
|
+
4. Commit using the plan's commit convention. Include only files the task declared.
|
|
79
|
+
|
|
80
|
+
**Do not:**
|
|
81
|
+
|
|
82
|
+
- Skip tasks or reorder them.
|
|
83
|
+
- Modify files outside the phase's declared boundaries.
|
|
84
|
+
- Introduce scope creep (features not in the plan).
|
|
85
|
+
- Commit multiple tasks into one commit.
|
|
86
|
+
|
|
87
|
+
#### Step 3: Self-Review Between Tasks
|
|
88
|
+
|
|
89
|
+
After each task's commit, before starting the next task, do a brief self-review:
|
|
90
|
+
|
|
91
|
+
- Did this task fully implement what the plan specified?
|
|
92
|
+
- Do tests verify behavior (not just mock behavior)?
|
|
93
|
+
- Did I avoid overbuilding (YAGNI)?
|
|
94
|
+
- Does the current state allow the next task to begin cleanly?
|
|
95
|
+
|
|
96
|
+
If you find a defect, fix it and add a follow-up commit within the task boundary using the plan's commit convention with a `fix` type (e.g., `fix({task-id}): {brief fix description}`). Do not amend the prior commit — keep history append-only. If you cannot fix it cleanly, escalate via the report format (DONE_WITH_CONCERNS).
|
|
97
|
+
|
|
98
|
+
#### Step 4: Phase-Wide Self-Review
|
|
99
|
+
|
|
100
|
+
After all tasks in the phase complete and commit:
|
|
101
|
+
|
|
102
|
+
- Do the phase's verification commands pass?
|
|
103
|
+
- Does the implementation align with the design / spec for this phase?
|
|
104
|
+
- Are there integration concerns between tasks you should flag?
|
|
105
|
+
|
|
106
|
+
#### Step 5: Return Summary
|
|
107
|
+
|
|
108
|
+
Return a structured report. DO NOT include full file contents or long excerpts. Be compact — the orchestrator uses this as its own view into your work.
|
|
109
|
+
|
|
110
|
+
Report format:
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
## Phase {phase-id} Implementation Report
|
|
114
|
+
|
|
115
|
+
**Status:** DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
|
|
116
|
+
**Phase:** {phase-id}
|
|
117
|
+
**Tasks executed:** {N} of {N}
|
|
118
|
+
**Commits:** {sha1}..{shaN}
|
|
119
|
+
|
|
120
|
+
### Task Outcomes
|
|
121
|
+
|
|
122
|
+
| Task | Status | Commit | Tests | Notes |
|
|
123
|
+
| ---- | ------ | ------ | ----- | ----- |
|
|
124
|
+
| {id} | done | {sha} | pass | - |
|
|
125
|
+
|
|
126
|
+
### Files Changed (phase-level)
|
|
127
|
+
|
|
128
|
+
- {path/to/file.ts} (created)
|
|
129
|
+
- {path/to/other.ts} (modified)
|
|
130
|
+
|
|
131
|
+
### Self-Review Observations
|
|
132
|
+
|
|
133
|
+
- {observation or "None"}
|
|
134
|
+
|
|
135
|
+
### Concerns (if DONE_WITH_CONCERNS)
|
|
136
|
+
|
|
137
|
+
- {concern or "N/A"}
|
|
138
|
+
|
|
139
|
+
### Reason (if BLOCKED or NEEDS_CONTEXT)
|
|
140
|
+
|
|
141
|
+
- {description of what you need or why you cannot proceed}
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
### Mode: `fix`
|
|
145
|
+
|
|
146
|
+
#### Step 1: Read Inputs
|
|
147
|
+
|
|
148
|
+
- Read the review artifact at `review_artifact`.
|
|
149
|
+
- Read your `prior_summary` to understand what was built.
|
|
150
|
+
- Read the phase section of `plan.md` to reconfirm scope.
|
|
151
|
+
|
|
152
|
+
#### Step 2: Apply Fixes
|
|
153
|
+
|
|
154
|
+
For each Critical and Important finding, in order:
|
|
155
|
+
|
|
156
|
+
1. Read the code location cited in the finding.
|
|
157
|
+
2. Apply the fix using the reviewer's guidance.
|
|
158
|
+
3. Run the task's verification commands (or phase-level commands) to verify the fix.
|
|
159
|
+
4. Commit the fix using the project's commit convention from the dispatch input, with type `fix` and the phase-id included per the plan's convention (for example: `fix({phase-id}): {brief description}` when the convention is `{type}({scope}): {description}`).
|
|
160
|
+
|
|
161
|
+
Do not expand scope beyond addressing the listed findings. Do not re-implement tasks that were not flagged.
|
|
162
|
+
|
|
163
|
+
#### Step 3: Self-Verify Fixes
|
|
164
|
+
|
|
165
|
+
After all fixes are applied, before returning:
|
|
166
|
+
|
|
167
|
+
- Re-run the phase's verification commands (tests, lint, type-check) to confirm no regressions.
|
|
168
|
+
- For each finding, verify the fix actually addresses the cited issue — re-read the fixed code and trace through the reviewer's stated concern.
|
|
169
|
+
- Confirm no files were modified outside the phase's boundary.
|
|
170
|
+
|
|
171
|
+
If a fix introduces a regression or doesn't address its finding, either re-fix within scope or escalate via DONE_WITH_CONCERNS.
|
|
172
|
+
|
|
173
|
+
#### Step 4: Return Fix Summary
|
|
174
|
+
|
|
175
|
+
```
|
|
176
|
+
## Phase {phase-id} Fix Report
|
|
177
|
+
|
|
178
|
+
**Status:** DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
|
|
179
|
+
**Phase:** {phase-id}
|
|
180
|
+
**Findings addressed:** {N} critical, {N} important
|
|
181
|
+
**Commits:** {sha1}..{shaN}
|
|
182
|
+
|
|
183
|
+
### Fix Outcomes
|
|
184
|
+
|
|
185
|
+
| Finding | Status | Commit | Notes |
|
|
186
|
+
| ------- | ------ | ------ | ----- |
|
|
187
|
+
| {id} | fixed | {sha} | - |
|
|
188
|
+
|
|
189
|
+
### Unresolved Findings (if any)
|
|
190
|
+
|
|
191
|
+
- {finding id}: {reason it was not fixed}
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
## Escalation Protocol
|
|
195
|
+
|
|
196
|
+
- **DONE:** All tasks completed, self-review clean, ready for reviewer.
|
|
197
|
+
- **DONE_WITH_CONCERNS:** Tasks completed but you have doubts. Examples: file is getting large but plan didn't address splitting; test coverage feels thin in one area; integration concern noted. Continue, but surface the concern.
|
|
198
|
+
- **NEEDS_CONTEXT:** A task requires artifact content (spec section, design decision, convention) that you cannot locate in the artifact set you were given. Stop and report what is missing. Do not guess.
|
|
199
|
+
- **BLOCKED:** A task cannot be completed as written — plan is inconsistent, external dependency unavailable, approach in plan would break existing code, etc. Stop and report what is blocking.
|
|
200
|
+
|
|
201
|
+
**Never:**
|
|
202
|
+
|
|
203
|
+
- Silently guess at an ambiguous requirement.
|
|
204
|
+
- Skip a task you cannot complete (report BLOCKED instead).
|
|
205
|
+
- Work outside your assigned phase.
|
|
206
|
+
- Modify files outside the phase's declared boundaries.
|
|
207
|
+
|
|
208
|
+
## Critical Rules
|
|
209
|
+
|
|
210
|
+
**TRUST ARTIFACTS, NOT SUMMARIES.** Verify by reading plan.md / design.md / spec.md. Do not take dispatch prose as ground truth where it conflicts with written artifacts.
|
|
211
|
+
|
|
212
|
+
**STAY IN SCOPE.** Only implement your assigned phase. Refuse scope creep politely by reporting DONE_WITH_CONCERNS with a note.
|
|
213
|
+
|
|
214
|
+
**COMMIT PER TASK.** One task, one commit. Use the plan's commit convention.
|
|
215
|
+
|
|
216
|
+
**READ ONCE.** Build your mental model at the start; do not re-read during execution.
|
|
217
|
+
|
|
218
|
+
**RETURN A COMPACT SUMMARY.** The orchestrator's context is precious. Summaries must fit in a small number of lines. Reference files and commits, do not quote them in full.
|
|
219
|
+
|
|
220
|
+
## Success Criteria
|
|
221
|
+
|
|
222
|
+
- [ ] Every task in the phase implemented in plan order, each in its own commit
|
|
223
|
+
- [ ] Verification commands for every task pass (or failures explicitly reported)
|
|
224
|
+
- [ ] No files modified outside the phase's declared boundaries
|
|
225
|
+
- [ ] Self-review performed between tasks and at phase end
|
|
226
|
+
- [ ] Compact summary returned with status, task outcomes, files changed, and any concerns
|
|
227
|
+
- [ ] In `fix` mode: only listed findings addressed; no scope expansion
|
|
228
|
+
- [ ] In `fix` mode: all cited Critical/Important findings addressed, no scope expansion
|
|
229
|
+
- [ ] In `fix` mode: self-verification step completed — phase verification commands re-run, no regressions
|
|
230
|
+
- [ ] In `fix` mode: no files modified outside the phase's boundary
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oat-reviewer
|
|
3
|
-
version: 1.0.
|
|
3
|
+
version: 1.0.1
|
|
4
4
|
description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes review artifact to disk.
|
|
5
5
|
tools: Read, Bash, Grep, Glob, Write
|
|
6
6
|
color: yellow
|
|
@@ -39,8 +39,8 @@ You will be given a "Review Scope" block including:
|
|
|
39
39
|
- **project**: Path to project directory (e.g., `.oat/projects/shared/my-feature/`)
|
|
40
40
|
- **type**: `code` or `artifact`
|
|
41
41
|
- **scope**: What to review (`pNN-tNN` task, `pNN` phase, `pNN-pMM` contiguous phase range, `final`, `BASE..HEAD` range, or an artifact name like `spec` / `design`)
|
|
42
|
-
- **commits/range**: Git commits or SHA range for changed files
|
|
43
|
-
- **files_changed**:
|
|
42
|
+
- **commits/range**: Git commits or SHA range for changed files. For code review, this is the authoritative review surface.
|
|
43
|
+
- **files_changed**: Optional orientation hint listing files believed to be modified in scope. If this disagrees with the commit range, trust the commit range.
|
|
44
44
|
- **workflow_mode**: `spec-driven` | `quick` | `import` (default to `spec-driven` if absent)
|
|
45
45
|
- **artifact_paths**: Paths to available artifacts (spec/design/plan/implementation/discovery/import reference)
|
|
46
46
|
- **tasks_in_scope**: Task IDs being reviewed (if task/phase scope)
|
|
@@ -137,13 +137,14 @@ Workflow preferences let power users answer repetitive confirmation prompts once
|
|
|
137
137
|
|
|
138
138
|
### Preference keys
|
|
139
139
|
|
|
140
|
-
All
|
|
140
|
+
All seven workflow preference keys live under the `workflow.*` namespace:
|
|
141
141
|
|
|
142
142
|
- `workflow.hillCheckpointDefault` — `every` or `final`. Default HiLL checkpoint behavior in `oat-project-implement`: pause after every phase or only after the last phase. When unset, the skill prompts.
|
|
143
143
|
- `workflow.archiveOnComplete` — boolean. Skip the "Archive after completion?" prompt in `oat-project-complete`. When unset, the skill prompts.
|
|
144
144
|
- `workflow.createPrOnComplete` — boolean. Skip the "Open a PR?" prompt in `oat-project-complete`; when true, completion auto-triggers PR creation. When unset, the skill prompts.
|
|
145
145
|
- `workflow.postImplementSequence` — `wait`, `summary`, `pr`, or `docs-pr`. Controls what `oat-project-implement` chains after final review passes. `wait` stops without auto-chaining, `summary` runs only `oat-project-summary`, `pr` runs `oat-project-pr-final` (which auto-generates summary), `docs-pr` runs `oat-project-document` then `oat-project-pr-final`. When unset, the skill prompts.
|
|
146
146
|
- `workflow.reviewExecutionModel` — `subagent`, `inline`, or `fresh-session`. Default final-review execution model in `oat-project-implement`. `subagent` and `inline` run automatically. `fresh-session` is a soft preference: the skill prints guidance to run the review in another session but still offers escape hatches to `subagent` or `inline` if you change your mind. When unset, the skill prompts.
|
|
147
|
+
- `workflow.autoReviewAtHillCheckpoints` — boolean. Automatically run the extra lifecycle review when a HiLL checkpoint is reached. This does not control Tier 1 per-phase `oat-reviewer` gates, which run after each phase in Tier 1 regardless of this setting. When unset, the skill prompts.
|
|
147
148
|
- `workflow.autoNarrowReReviewScope` — boolean. Auto-narrow re-review scope to fix-task commits only in `oat-project-review-provide`. When unset, the skill prompts.
|
|
148
149
|
|
|
149
150
|
### Three-layer resolution
|
|
@@ -165,6 +166,7 @@ oat config set workflow.archiveOnComplete true --user
|
|
|
165
166
|
oat config set workflow.createPrOnComplete true --user
|
|
166
167
|
oat config set workflow.postImplementSequence pr --user
|
|
167
168
|
oat config set workflow.reviewExecutionModel subagent --user
|
|
169
|
+
oat config set workflow.autoReviewAtHillCheckpoints true --user
|
|
168
170
|
oat config set workflow.autoNarrowReReviewScope true --user
|
|
169
171
|
|
|
170
172
|
# Shared repo: team decision for this repo
|
|
@@ -186,6 +188,7 @@ Some preferences are **genuinely personal** — their correct value is the same
|
|
|
186
188
|
|
|
187
189
|
- `workflow.hillCheckpointDefault` — your personal tolerance for mid-implementation interruption
|
|
188
190
|
- `workflow.reviewExecutionModel` — depends on your provider environment (Claude Code, Cursor, Codex), not the repo
|
|
191
|
+
- `workflow.autoReviewAtHillCheckpoints` — your preference for automatic lifecycle review at HiLL checkpoints. Shared/local config can still override this when a repo should behave differently.
|
|
189
192
|
- `workflow.autoNarrowReReviewScope` — pure personal workflow preference, no per-repo interaction
|
|
190
193
|
|
|
191
194
|
Other preferences **depend on per-repo configuration** to be safe. These should be set at `--shared` (in each repo where they apply), not `--user`:
|
|
@@ -202,6 +205,7 @@ Other preferences **depend on per-repo configuration** to be safe. These should
|
|
|
202
205
|
# Personal defaults (apply everywhere)
|
|
203
206
|
oat config set workflow.hillCheckpointDefault final --user
|
|
204
207
|
oat config set workflow.reviewExecutionModel subagent --user
|
|
208
|
+
oat config set workflow.autoReviewAtHillCheckpoints true --user
|
|
205
209
|
oat config set workflow.autoNarrowReReviewScope true --user
|
|
206
210
|
|
|
207
211
|
# Per-repo team decisions (set in each repo where they apply)
|
|
@@ -217,9 +221,17 @@ oat config set workflow.archiveOnComplete false --local # "I don't want to arch
|
|
|
217
221
|
|
|
218
222
|
### Relationship to `autoReviewAtCheckpoints`
|
|
219
223
|
|
|
220
|
-
|
|
224
|
+
`workflow.autoReviewAtHillCheckpoints` is the preferred key. It controls whether `oat-project-implement` runs the extra lifecycle review when a configured HiLL checkpoint is reached.
|
|
221
225
|
|
|
222
|
-
|
|
226
|
+
This does not control Tier 1 phase gate reviews. Tier 1 always runs `oat-reviewer` after each phase. The workflow key only controls the additional `oat-project-review-provide` lifecycle review at HiLL checkpoints.
|
|
227
|
+
|
|
228
|
+
The legacy top-level `.oat/config.json` key `autoReviewAtCheckpoints` is still read as a fallback for backward compatibility. Prefer the workflow key for new config:
|
|
229
|
+
|
|
230
|
+
```bash
|
|
231
|
+
oat config set workflow.autoReviewAtHillCheckpoints true --user
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
If you enable this plus the other workflow preferences, you get a near-uninterrupted lifecycle: lifecycle review runs at HiLL checkpoints, fix tasks are converted automatically, and the workflow preferences skip every remaining confirmation prompt.
|
|
223
235
|
|
|
224
236
|
## Provider sync config is different
|
|
225
237
|
|
|
@@ -69,12 +69,13 @@ What the skill adds over the raw CLI:
|
|
|
69
69
|
- **Post-scaffold patches for open CLI gaps.** Applied only when capability detection shows the CLI hasn't closed the gap. Each patch is labeled (e.g., `<!-- FP-12 patch -->`) so it can be removed deterministically when the upstream fix lands:
|
|
70
70
|
- **FP-11** — Turbopack `root` for nested-standalone Fumadocs apps (suppresses the multiple-lockfile warning)
|
|
71
71
|
- **FP-12** — `export const metadata = { title, description }` in `app/layout.tsx` (the only thing that populates page `<title>`, meta description, and Open Graph — `DocsLayout.branding.title` only renders nav chrome, and `createDocsConfig()` ignores `title` / `description` entirely)
|
|
72
|
-
- **FP-13** —
|
|
72
|
+
- **FP-13** — four scaffold-content fixes (empty per-page `description:` frontmatter, bare install/build commands missing `--filter` or `cd`-prefix for monorepo/nested shapes, false `docs:lint` claim when `lint=none`, Node version line that doesn't match the consuming repo's `.nvmrc` / `engines.node`)
|
|
73
73
|
- **FP-15** — writes a task-framed `<appRoot>/AGENTS.md` bridge file when the CLI hasn't scaffolded one. The bridge is the docs app's runtime agent reference (separate audience from `docs/contributing.md`)
|
|
74
74
|
- **FP-16** — rewrites `docs/index.md` `## Contents` links to the `.md`-suffixed form that `@open-agent-toolkit/docs-transforms` normalizes at build time (agent-friendlier than extension-less; routes correctly)
|
|
75
75
|
- **FP-17** — trims `docs/contributing.md`'s "Agent guidance" section to a one-line pointer at the docs-app `AGENTS.md`, restoring the three-surfaces separation
|
|
76
76
|
- **Build verification.** Runs install + build, classifies failures against known patterns, stops on unknown errors rather than guessing.
|
|
77
77
|
- **Config inspection.** Reads `.oat/config.json` back, verifies paths exist on disk, handles the nested-standalone dual-config case, and collects the `requireForProjectCompletion` opt-in explicitly.
|
|
78
|
+
- **Root-build explanation.** When the CLI safely patches a compatible Turbo root `build` script, the walkthrough explains why the filter was added, shows the diff shape, and documents how to adjust or revert it. When the CLI skips the patch, the walkthrough relays the recommended manual snippet.
|
|
78
79
|
- **Educational walkthrough.** Seven sections covering the `documentation` config, the two-`index.md` model, the `## Contents` contract (with extension discipline), the three agent-instruction surfaces (root `AGENTS.md` pointer / docs-app `AGENTS.md` / `docs/contributing.md`), Fumadocs internals (or MkDocs Minimum Contract), and the OAT docs ecosystem (`oat-project-document`, `oat-docs-analyze`, `oat-docs-apply`).
|
|
79
80
|
- **Optional content kickoff.** Hands off to `oat-docs-analyze` + `oat-docs-apply` if you want to populate initial repo-specific content immediately.
|
|
80
81
|
|
|
@@ -108,6 +109,12 @@ oat docs init --app-name my-docs --framework mkdocs --yes
|
|
|
108
109
|
|
|
109
110
|
Use 3b when you want a fully headless scaffold (CI, automation) and can accept the raw CLI output without the guided post-patches.
|
|
110
111
|
|
|
112
|
+
For compatible Turbo monorepos, the CLI also patches the repo-root
|
|
113
|
+
`package.json` by default so root `pnpm build` excludes the new docs app and a
|
|
114
|
+
root `build:docs` script is available for docs-only builds. Use
|
|
115
|
+
`--no-root-patch` to opt out, or `--dry-run` to preview the diff without
|
|
116
|
+
writing it.
|
|
117
|
+
|
|
111
118
|
## 3a. Migrating from MkDocs (optional)
|
|
112
119
|
|
|
113
120
|
If you have an existing MkDocs site and want to switch to Fumadocs, use the
|
|
@@ -141,6 +148,10 @@ For **Fumadocs** apps, the docs index is generated automatically via
|
|
|
141
148
|
oat docs generate-index --docs-dir docs
|
|
142
149
|
```
|
|
143
150
|
|
|
151
|
+
The generated app-root `index.md` is machine-owned and now starts with an
|
|
152
|
+
`AUTOGENERATED` warning comment. Edit authored pages under `docs/`, not the
|
|
153
|
+
generated root index.
|
|
154
|
+
|
|
144
155
|
## 5. Analyze the docs surface
|
|
145
156
|
|
|
146
157
|
Use the skill, not the CLI stub, for the real analysis workflow.
|
|
@@ -39,6 +39,8 @@ Key behavior:
|
|
|
39
39
|
- defaults to `apps/<app-name>` for monorepos
|
|
40
40
|
- defaults to `<app-name>/` at repo root for single-package repos
|
|
41
41
|
- sets `documentation.tooling`, `documentation.root`, and `documentation.index` in `.oat/config.json`
|
|
42
|
+
- when the repo root exposes a compatible Turbo `scripts.build`, patches it to exclude the new docs app from the default root build and adds a root-level `build:docs` script
|
|
43
|
+
- prints a unified diff before writing the root `package.json` change and returns a manual snippet when the patch is skipped because the build script is missing, non-Turbo, or ambiguous
|
|
42
44
|
|
|
43
45
|
Fumadocs scaffold:
|
|
44
46
|
|
|
@@ -60,6 +62,7 @@ Supported flags:
|
|
|
60
62
|
- `--description <text>` (site description, optional)
|
|
61
63
|
- `--lint <none|markdownlint-cli2>`
|
|
62
64
|
- `--format <oxfmt|none>`
|
|
65
|
+
- `--no-root-patch`
|
|
63
66
|
- `--yes`
|
|
64
67
|
|
|
65
68
|
Examples:
|
|
@@ -117,6 +120,7 @@ Key behavior:
|
|
|
117
120
|
- includes descriptions from frontmatter when present
|
|
118
121
|
- outputs to app root (`index.md`) by default, not inside the docs directory
|
|
119
122
|
- updates `documentation.index` in `.oat/config.json`
|
|
123
|
+
- prepends an `AUTOGENERATED` warning comment to the output and rewrites the file on every run; do not hand-edit the generated `index.md`
|
|
120
124
|
- sorting: `index.md` first, then directories before files, then lexical
|
|
121
125
|
|
|
122
126
|
Supported flags:
|
|
@@ -22,17 +22,17 @@ The CLI is also a standalone value path. You can use `oat init`, `oat sync`, `oa
|
|
|
22
22
|
|
|
23
23
|
## Command Groups
|
|
24
24
|
|
|
25
|
-
| Command group | What it covers
|
|
26
|
-
| ----------------------------------------------- |
|
|
27
|
-
| `oat init` | Bootstrap canonical OAT directories, sync config, optional hooks, and guided setup.
|
|
28
|
-
| `oat tools ...` | Install, inspect, update, and remove bundled OAT tool packs and assets.
|
|
29
|
-
| `oat backlog ...` / `oat local ...` | File-backed backlog helpers, local path sync, and local-only operational support.
|
|
30
|
-
| `oat config ...` / `oat instructions ...` | Config discovery, source-aware config dumps, supported mutations, and instruction-integrity helpers.
|
|
31
|
-
| `oat state ...` / `oat index ...` / `internal` | Repo dashboard refresh, repo indexing, validation helpers, and diagnostics.
|
|
32
|
-
| `oat docs ...` | Docs app bootstrap, migration, index generation, nav sync, and docs workflow entrypoints.
|
|
33
|
-
| `oat status` / `oat sync` / `oat providers ...` | Provider sync, drift inspection, provider configuration, and adoption behavior.
|
|
34
|
-
| `oat project ...` / `oat cleanup ...` | Project scaffolding, active-project status inspection, tracked-project listing,
|
|
35
|
-
| `oat repo ...` | Repository-level analysis workflows, currently centered on PR comments.
|
|
25
|
+
| Command group | What it covers | Go deeper |
|
|
26
|
+
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
|
|
27
|
+
| `oat init` | Bootstrap canonical OAT directories, sync config, optional hooks, and guided setup. | [CLI Bootstrap](../cli-utilities/bootstrap.md) |
|
|
28
|
+
| `oat tools ...` | Install, inspect, update, and remove bundled OAT tool packs and assets. | [Tool Packs](../cli-utilities/tool-packs.md) |
|
|
29
|
+
| `oat backlog ...` / `oat local ...` | File-backed backlog helpers, local path sync, and local-only operational support. | [Config and Local State](../cli-utilities/config-and-local-state.md) |
|
|
30
|
+
| `oat config ...` / `oat instructions ...` | Config discovery, source-aware config dumps, supported mutations, and instruction-integrity helpers. | [Config and Local State](../cli-utilities/config-and-local-state.md) |
|
|
31
|
+
| `oat state ...` / `oat index ...` / `internal` | Repo dashboard refresh, repo indexing, validation helpers, and diagnostics. | [Config and Local State](../cli-utilities/config-and-local-state.md) |
|
|
32
|
+
| `oat docs ...` | Docs app bootstrap, migration, index generation, nav sync, and docs workflow entrypoints. | [Docs Tooling Commands](../docs-tooling/commands.md) |
|
|
33
|
+
| `oat status` / `oat sync` / `oat providers ...` | Provider sync, drift inspection, provider configuration, and adoption behavior. | [Provider Sync](../provider-sync/index.md) |
|
|
34
|
+
| `oat project ...` / `oat cleanup ...` | Project scaffolding, active-project status inspection, tracked-project listing, plan validation, and project/artifact cleanup commands. | [Workflow & Projects](../workflows/projects/index.md) |
|
|
35
|
+
| `oat repo ...` | Repository-level analysis workflows, currently centered on PR comments. | [Repository Analysis](../workflows/projects/repo-analysis.md) |
|
|
36
36
|
|
|
37
37
|
Notable inspection commands introduced in the current CLI surface:
|
|
38
38
|
|
|
@@ -40,6 +40,8 @@ Notable inspection commands introduced in the current CLI surface:
|
|
|
40
40
|
- `oat project status --json` - full parsed state for the active tracked project
|
|
41
41
|
- `oat project list --json` - summary state for tracked projects under the configured projects root
|
|
42
42
|
- `oat project complete-state <project-path>` - apply the canonical completed-state mutation to a project's `state.md`; used by `oat-project-complete` during lifecycle closeout
|
|
43
|
+
- `oat project validate-plan --project-path <path>` - validates `oat_plan_parallel_groups` metadata in `plan.md`; exits non-zero on invalid. See [Implementation Execution](../workflows/projects/implementation-execution.md#validating-plan-metadata).
|
|
44
|
+
- `oat project set-mode` — deprecated no-op. Execution mode is no longer user-selectable; emits a deprecation warning and preserves the `--json` contract.
|
|
43
45
|
|
|
44
46
|
## `oat config` surface flags
|
|
45
47
|
|
|
@@ -51,17 +53,18 @@ Notable inspection commands introduced in the current CLI surface:
|
|
|
51
53
|
|
|
52
54
|
When no flag is passed, the CLI picks a sensible default per key type: structural keys (`projects.root`, `documentation.*`, etc.) go to shared, state keys (`activeProject`, etc.) go to local, workflow preferences (`workflow.*`) go to local. Pass at most one flag — the command rejects multiple surface flags.
|
|
53
55
|
|
|
54
|
-
Per-key restrictions apply: structural keys can only be written at shared scope, most state keys can only be written at local scope (`activeIdea` is the exception — it accepts both local and user), and
|
|
56
|
+
Per-key restrictions apply: structural keys can only be written at shared scope, most state keys can only be written at local scope (`activeIdea` is the exception — it accepts both local and user), and workflow preference keys accept any non-auto surface. Legacy `autoReviewAtCheckpoints` remains shared-only; prefer `workflow.autoReviewAtHillCheckpoints`.
|
|
55
57
|
|
|
56
58
|
## `workflow.*` preference keys
|
|
57
59
|
|
|
58
|
-
The `workflow.*` namespace holds user-facing workflow preferences that let you answer repetitive confirmation prompts once and have OAT skills respect the answer automatically.
|
|
60
|
+
The `workflow.*` namespace holds user-facing workflow preferences that let you answer repetitive confirmation prompts once and have OAT skills respect the answer automatically. Seven keys:
|
|
59
61
|
|
|
60
62
|
- `workflow.hillCheckpointDefault` (`every` | `final`) — default HiLL checkpoint behavior in `oat-project-implement`
|
|
61
63
|
- `workflow.archiveOnComplete` (`boolean`) — skip the archive prompt in `oat-project-complete`
|
|
62
64
|
- `workflow.createPrOnComplete` (`boolean`) — skip the "Open a PR?" prompt in `oat-project-complete`
|
|
63
65
|
- `workflow.postImplementSequence` (`wait` | `summary` | `pr` | `docs-pr`) — post-implementation chaining behavior
|
|
64
66
|
- `workflow.reviewExecutionModel` (`subagent` | `inline` | `fresh-session`) — default final-review execution model
|
|
67
|
+
- `workflow.autoReviewAtHillCheckpoints` (`boolean`) — auto-run the extra lifecycle review at HiLL checkpoints
|
|
65
68
|
- `workflow.autoNarrowReReviewScope` (`boolean`) — auto-narrow re-review scope to fix-task commits
|
|
66
69
|
|
|
67
|
-
All
|
|
70
|
+
All seven keys resolve through the 3-layer precedence chain (`env > local > shared > user > default`). See [Workflow preferences in the Configuration guide](../cli-utilities/configuration.md#workflow-preferences-workflow) for full descriptions, surface guidance, and cross-repo foot-gun examples.
|
|
@@ -91,23 +91,23 @@ Legacy `.oat/active-project` / `.oat/projects-root` / `.oat/active-idea` files m
|
|
|
91
91
|
|
|
92
92
|
Current schema keys:
|
|
93
93
|
|
|
94
|
-
| Key | Type | Default | Description
|
|
95
|
-
| ------------------------------------------- | ---------- | ------------------------ |
|
|
96
|
-
| `version` | `number` | `1` | Schema version
|
|
97
|
-
| `worktrees.root` | `string` | `".worktrees"` | Root directory for git worktrees (repo-relative or absolute)
|
|
98
|
-
| `projects.root` | `string` | `".oat/projects/shared"` | Default root directory for OAT projects
|
|
99
|
-
| `localPaths` | `string[]` | - | Gitignored directories to sync between main repo and worktrees. Supports glob patterns. Managed via `oat local add/remove`.
|
|
100
|
-
| `documentation.root` | `string` | - | Root directory containing documentation source files (e.g., `apps/docs/docs`)
|
|
101
|
-
| `documentation.tooling` | `string` | - | Documentation framework identifier (`mkdocs` or `fumadocs`)
|
|
102
|
-
| `documentation.config` | `string` | - | Path to the documentation framework config file (e.g., `mkdocs.yml`, `next.config.js`)
|
|
103
|
-
| `documentation.index` | `string` | - | Path to the docs surface entry point (e.g., `index.md` for Fumadocs, `mkdocs.yml` for MkDocs). Set by `oat docs init` and updated by `oat docs generate-index`.
|
|
104
|
-
| `documentation.requireForProjectCompletion` | `boolean` | `false` | When `true`, OAT project completion gates require documentation to be updated
|
|
105
|
-
| `git.defaultBranch` | `string` | `"main"` | Default branch for PR creation. Auto-detected during `oat init` via `gh repo view` or `origin/HEAD`. Used by `oat-project-pr-final` and `oat-project-pr-progress`.
|
|
106
|
-
| `
|
|
107
|
-
| `archive.s3Uri` | `string` | - | Base S3 URI for repo-scoped archived project sync, for example `s3://bucket/oat-archive`
|
|
108
|
-
| `archive.s3SyncOnComplete` | `boolean` | `false` | When `true`, `oat-project-complete` uploads the archived project to the configured S3 archive after local archive succeeds
|
|
109
|
-
| `archive.summaryExportPath` | `string` | - | Repo-relative directory where completion exports `summary.md` as a dated snapshot like `20260401-<project-name>.md` for durable tracked reference
|
|
110
|
-
| `archive.wrapUpExportPath` | `string` | - | Repo-relative directory where `oat-wrap-up` writes dated reports like `20260413-wrap-up-past-week.md`; when unset, the skill falls back to `.oat/repo/reference/wrap-ups/`
|
|
94
|
+
| Key | Type | Default | Description |
|
|
95
|
+
| ------------------------------------------- | ---------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
96
|
+
| `version` | `number` | `1` | Schema version |
|
|
97
|
+
| `worktrees.root` | `string` | `".worktrees"` | Root directory for git worktrees (repo-relative or absolute) |
|
|
98
|
+
| `projects.root` | `string` | `".oat/projects/shared"` | Default root directory for OAT projects |
|
|
99
|
+
| `localPaths` | `string[]` | - | Gitignored directories to sync between main repo and worktrees. Supports glob patterns. Managed via `oat local add/remove`. |
|
|
100
|
+
| `documentation.root` | `string` | - | Root directory containing documentation source files (e.g., `apps/docs/docs`) |
|
|
101
|
+
| `documentation.tooling` | `string` | - | Documentation framework identifier (`mkdocs` or `fumadocs`) |
|
|
102
|
+
| `documentation.config` | `string` | - | Path to the documentation framework config file (e.g., `mkdocs.yml`, `next.config.js`) |
|
|
103
|
+
| `documentation.index` | `string` | - | Path to the docs surface entry point (e.g., `index.md` for Fumadocs, `mkdocs.yml` for MkDocs). Set by `oat docs init` and updated by `oat docs generate-index`. |
|
|
104
|
+
| `documentation.requireForProjectCompletion` | `boolean` | `false` | When `true`, OAT project completion gates require documentation to be updated |
|
|
105
|
+
| `git.defaultBranch` | `string` | `"main"` | Default branch for PR creation. Auto-detected during `oat init` via `gh repo view` or `origin/HEAD`. Used by `oat-project-pr-final` and `oat-project-pr-progress`. |
|
|
106
|
+
| `workflow.autoReviewAtHillCheckpoints` | `boolean` | unset | When `true`, completing a HiLL checkpoint automatically runs the extra lifecycle review. Does not control Tier 1 per-phase `oat-reviewer` gates. Can be overridden per-project via `oat_auto_review_at_hill_checkpoints` in `plan.md` frontmatter. Legacy `autoReviewAtCheckpoints` remains a fallback. |
|
|
107
|
+
| `archive.s3Uri` | `string` | - | Base S3 URI for repo-scoped archived project sync, for example `s3://bucket/oat-archive` |
|
|
108
|
+
| `archive.s3SyncOnComplete` | `boolean` | `false` | When `true`, `oat-project-complete` uploads the archived project to the configured S3 archive after local archive succeeds |
|
|
109
|
+
| `archive.summaryExportPath` | `string` | - | Repo-relative directory where completion exports `summary.md` as a dated snapshot like `20260401-<project-name>.md` for durable tracked reference |
|
|
110
|
+
| `archive.wrapUpExportPath` | `string` | - | Repo-relative directory where `oat-wrap-up` writes dated reports like `20260413-wrap-up-past-week.md`; when unset, the skill falls back to `.oat/repo/reference/wrap-ups/` |
|
|
111
111
|
|
|
112
112
|
All `documentation.*` keys are managed via `oat config get/set` and are set automatically by `oat docs init`.
|
|
113
113
|
The `git.defaultBranch` key is auto-detected during `oat init` and can be overridden via `oat config set git.defaultBranch <branch>`.
|
|
@@ -34,6 +34,40 @@ Mode-sensitive notes:
|
|
|
34
34
|
|
|
35
35
|
Artifacts are the project system of record; automation and routing should derive from these files, not memory.
|
|
36
36
|
|
|
37
|
+
### plan.md frontmatter
|
|
38
|
+
|
|
39
|
+
`plan.md` carries frontmatter that the implementation skill consumes. Notable fields:
|
|
40
|
+
|
|
41
|
+
- `oat_plan_hill_phases` — list of phase IDs to pause at for HiLL checkpoints.
|
|
42
|
+
- `oat_plan_parallel_groups` — declares which phases may execute concurrently in worktrees. See below.
|
|
43
|
+
|
|
44
|
+
#### oat_plan_parallel_groups
|
|
45
|
+
|
|
46
|
+
Declare phase groups that run in parallel during `oat-project-implement`:
|
|
47
|
+
|
|
48
|
+
```yaml
|
|
49
|
+
oat_plan_parallel_groups: [['p02', 'p03'], ['p04', 'p05']]
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Each inner array is a group of phases that execute concurrently in their own worktrees and merge back to the orchestration branch in plan order. Phases not listed in any group run sequentially.
|
|
53
|
+
|
|
54
|
+
**Semantics:**
|
|
55
|
+
|
|
56
|
+
- Empty or missing field → fully sequential, no worktrees created (default).
|
|
57
|
+
- Each group must contain **2 or more** phases — singleton groups are rejected.
|
|
58
|
+
- Every phase ID must exist in the plan body.
|
|
59
|
+
- No phase may appear in more than one group.
|
|
60
|
+
- Parallelism is only honored at Tier 1 (native subagents). Tier 2 degrades parallel groups to sequential inline execution.
|
|
61
|
+
|
|
62
|
+
**Authoring responsibility:**
|
|
63
|
+
|
|
64
|
+
- `oat-project-plan` proposes parallel groups when phases have file-disjoint task sets; it never infers parallelism silently.
|
|
65
|
+
- Phases listed in a group should have no file-level overlap. Overlap will produce merge conflicts during fan-in that stop the run.
|
|
66
|
+
|
|
67
|
+
**Validation:**
|
|
68
|
+
|
|
69
|
+
Before dispatching, `oat-project-implement` invokes `oat project validate-plan --project-path "${PROJECT_PATH}"`. Non-zero exit blocks the run. See [CLI Reference](../../reference/cli-reference.md) and [Implementation Execution](implementation-execution.md) for details.
|
|
70
|
+
|
|
37
71
|
## Reference artifacts
|
|
38
72
|
|
|
39
73
|
- `.oat/templates/*.md`
|