agentera 3.0.0-dev.17 → 3.0.0-dev.19

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.
Files changed (52) hide show
  1. package/bundle/CHANGELOG.md +20 -0
  2. package/bundle/UPGRADE.md +27 -2
  3. package/bundle/references/cli/vocabulary.md +1 -1
  4. package/bundle/skills/agentera/SKILL.md +1 -1
  5. package/bundle/skills/agentera/capabilities/orchestrate/schemas/artifacts.yaml +2 -1
  6. package/bundle/skills/agentera/capabilities/plan/schemas/artifacts.yaml +7 -6
  7. package/bundle/skills/agentera/schemas/artifacts/plan.yaml +258 -6
  8. package/dist/capabilities/orchestrate/instructions.js +6 -1
  9. package/dist/capabilities/orchestrate/instructions.js.map +1 -1
  10. package/dist/capabilities/plan/instructions.js +1 -1
  11. package/dist/capabilities/plan/instructions.js.map +1 -1
  12. package/dist/cli/capabilityContext/build.js +16 -3
  13. package/dist/cli/capabilityContext/build.js.map +1 -1
  14. package/dist/cli/capabilityContext/orchestration.js +12 -2
  15. package/dist/cli/capabilityContext/orchestration.js.map +1 -1
  16. package/dist/cli/capabilityContext/planState.js +15 -7
  17. package/dist/cli/capabilityContext/planState.js.map +1 -1
  18. package/dist/cli/capabilityContext/progress.js +42 -7
  19. package/dist/cli/capabilityContext/progress.js.map +1 -1
  20. package/dist/cli/capabilityContext/startup.js +2 -0
  21. package/dist/cli/capabilityContext/startup.js.map +1 -1
  22. package/dist/cli/commands/lint.js +12 -5
  23. package/dist/cli/commands/lint.js.map +1 -1
  24. package/dist/cli/commands/schema.js +1 -1
  25. package/dist/cli/commands/schema.js.map +1 -1
  26. package/dist/cli/commands/state/plan.js +73 -8
  27. package/dist/cli/commands/state/plan.js.map +1 -1
  28. package/dist/cli/orientation.js +32 -33
  29. package/dist/cli/orientation.js.map +1 -1
  30. package/dist/cli/planArtifacts.js +105 -28
  31. package/dist/cli/planArtifacts.js.map +1 -1
  32. package/dist/cli/planLifecycleState.js +34 -0
  33. package/dist/cli/planLifecycleState.js.map +1 -0
  34. package/dist/cli/prime-blob.js +2 -2
  35. package/dist/cli/prime-blob.js.map +1 -1
  36. package/dist/hooks/validateArtifact/schema.js +8 -2
  37. package/dist/hooks/validateArtifact/schema.js.map +1 -1
  38. package/dist/state/write/explain.js +4 -0
  39. package/dist/state/write/explain.js.map +1 -1
  40. package/dist/state/write/operations.js +41 -2
  41. package/dist/state/write/operations.js.map +1 -1
  42. package/dist/state/write/transaction.js +257 -89
  43. package/dist/state/write/transaction.js.map +1 -1
  44. package/dist/upgrade/migrateArtifactsV1ToV2.js +1 -1
  45. package/dist/upgrade/migrateArtifactsV1ToV2.js.map +1 -1
  46. package/dist/upgrade/migrateArtifactsV2ToV3.js +172 -12
  47. package/dist/upgrade/migrateArtifactsV2ToV3.js.map +1 -1
  48. package/dist/upgrade/upgradeOrchestrator.js +3 -2
  49. package/dist/upgrade/upgradeOrchestrator.js.map +1 -1
  50. package/dist/validate/selfAudit.js +1 -1
  51. package/dist/validate/selfAudit.js.map +1 -1
  52. package/package.json +1 -1
@@ -9,11 +9,31 @@
9
9
 
10
10
  ### Changed
11
11
 
12
+ - Changed `agentera upgrade --only artifacts` to preview and apply deterministic
13
+ plan lifecycle migration for docs-mapped current plans and archives. Legacy
14
+ `active` and `completed` plan statuses become `open` and `complete` without
15
+ rewriting retained task evidence; archive recency now uses persisted creation
16
+ dates instead of file modification times.
17
+ - Changed plan reads to normalize legacy `active` and `completed` statuses within
18
+ the current-plan and archive boundary, with structured diagnostics for
19
+ malformed current plans and archives.
20
+ - Clarified that `set-plan-status --status complete` closes the active plan
21
+ lifecycle after every task completes, while `archive` moves it into
22
+ non-executable history.
23
+ - Defined plan lifecycle status as `open` or `complete`, with activity derived from the current-plan path and forced unfinished archives remaining open and non-executable.
24
+ - Enforced plan lifecycle surface classification with a bounded repository scan covering readers, writers, migrators, schemas, adapters, fixtures, and documented commitments.
25
+ - Expanded lifecycle classification to every repository surface outside documented vendor, cache, generated-output, snapshot, symlink, and secret exclusions.
12
26
  - Changed v3 development-channel dry-runs without `--runtime` to show all active runtime lifecycle findings; generated lifecycle apply commands include `--runtime all --yes`, while apply without a selector remains app-only.
13
27
  - Changed lifecycle repair to fail closed on incomplete ownership provenance, isolate narrowed runtime selectors, and count explicit Claude cleanup separately from active-runtime work.
14
28
  - Changed corrupt or disconnected ownership-journal blockers to report stable causes without volatile event filenames across preview and apply.
15
29
  - Synchronized lifecycle projections across prime, status, project integration, and doctor while keeping Cursor CLI required, IDE conditional, and Claude cleanup explicit.
16
30
 
31
+ ### Fixed
32
+
33
+ - Fixed `agentera state plan create` and `archive` publication to use stable archive identities across retries, validate final serialized bytes with strict prose lint and schema checks, and retain canonical `overall acceptance` vocabulary.
34
+ - Fixed `agentera state plan`: `set-status --task` accepts task values, and `set-plan-status` accepts `open` or `complete`.
35
+ - Fixed plan discovery to derive activity from canonical paths: archive-only history is non-executable and cannot trigger a Build completion sweep; next work is dependency-ready, lifecycle diagnostics are shared, and evaluator state is retry-safe through `state plan record-evaluation`.
36
+
17
37
  ## [3.0.0] · 2026-07-12
18
38
 
19
39
  ### Key highlights
package/bundle/UPGRADE.md CHANGED
@@ -147,7 +147,20 @@ npx -y agentera@next report refresh --import-source claude
147
147
  Imported records carry `historical_import` provenance, have no active runtime
148
148
  ID, and remain excluded from default active-runtime analytics.
149
149
 
150
- ## v2 to v3 project migration
150
+ ## Recommended upgrade v1 & v2 stable channel
151
+
152
+ The stable `@latest` channel remains on the supported 2.x line. Preview before
153
+ applying an in-line upgrade:
154
+
155
+ ```bash
156
+ npx -y agentera@latest upgrade --dry-run
157
+ npx -y agentera@latest upgrade --yes
158
+ ```
159
+
160
+ Use the v3 development migration below only when you explicitly intend to
161
+ leave the stable line.
162
+
163
+ ## Upgrading v2 to v3 development channel (irreversible)
151
164
 
152
165
  Use the development channel explicitly while 3.0 is on `@next`:
153
166
 
@@ -160,6 +173,10 @@ The preview reports artifact migration, app migration, legacy cleanup, and any
160
173
  explicitly selected runtime work as separate phases. It does not cross the
161
174
  major boundary or mutate the project without `--yes`.
162
175
 
176
+ Forward migration to v3 is one-way. Returning to the prior Python 2.x support
177
+ line is permanently unsupported; review the development-channel preview before
178
+ applying it.
179
+
163
180
  Useful phase filters are repeatable:
164
181
 
165
182
  ```bash
@@ -168,6 +185,12 @@ npx -y agentera@next upgrade --only runtime --dry-run
168
185
  npx -y agentera@next upgrade --only cleanup --dry-run
169
186
  ```
170
187
 
188
+ `--only runtime` filters the v2-to-v3 project-migration runtime phase. It does
189
+ not select an Agentera runtime identity or limit lifecycle diagnosis. Use
190
+ `--runtime all|opencode|codex|cursor|copilot` for lifecycle work; it cannot be
191
+ combined with `--only`. Development-channel dry-runs without `--runtime` still
192
+ observe all active lifecycle runtimes.
193
+
171
194
  ## Verification and recovery
172
195
 
173
196
  After apply:
@@ -177,7 +200,9 @@ npx -y agentera@next doctor --format json
177
200
  npx -y agentera@next prime --format json
178
201
  ```
179
202
 
180
- `upgrade --verify` adds doctor and capability-schema checks to an upgrade run.
203
+ `upgrade --verify` without `--yes` is a read-only doctor and capability-context
204
+ verification. With `--yes`, it runs those checks after the approved upgrade
205
+ apply. Lifecycle selections with `--verify` require `--yes`.
181
206
  `upgrade --restore` restores the latest supported app-migration snapshot; it
182
207
  does not bypass lifecycle ownership or trust checks. For lifecycle partial
183
208
  failure, rerun the same preview and apply selection. Do not delete or hand-edit
@@ -301,7 +301,7 @@ tests, labels, or active state.
301
301
  | Decision gate | Explicit condition-based branch before proceeding. | Optimize keep/discard decision. |
302
302
  | Exit-early stop condition | Stop condition when work is already complete or unnecessary. | Docs current, no stale work found. |
303
303
  | Behavioral verification gate | Build check that behavior was verified against real project state. | Tests, builds, or manual verification. |
304
- | Pre-write self-audit | Prose check for verbosity mismatch, abstraction creep, and filler accumulation. | `agentera lint --artifact <ARTIFACT>` exposes the checks through the CLI. |
304
+ | Draft lint preview | Optional early feedback for verbosity mismatch, abstraction creep, and filler accumulation. | `agentera check lint --artifact <ARTIFACT>` previews a draft; the typed writer validates final bytes when publishing. |
305
305
  | Plan-completion sweep | Build cleanup when plan tasks finish. | Progress rollup, changelog, TODO, health cross-reference, archive. |
306
306
  | Worker spawn | Isolated implementation or measurement by a worker through the host subagent mechanism. | Build and optimize can use it. |
307
307
  | Stale-base awareness | Prevent workers from branching from old `origin/main` or stale HEAD. | Use pre-spawn Git commits before spawning workers. |
@@ -169,7 +169,7 @@ Common mutations:
169
169
  - `agentera state decisions append ... --format json`
170
170
  - `agentera state decisions update --number N ... --format json`
171
171
  - `agentera state plan create --input plan.yaml --format json`
172
- - `agentera state plan append|update|set-status ... --format json`
172
+ - `agentera state plan append|update|set-status|set-plan-status ... --format json`
173
173
  - `agentera state plan archive --format json`
174
174
  - `agentera state health append --input audit.yaml --format json`
175
175
 
@@ -7,7 +7,8 @@ ARTIFACTS:
7
7
  Orchestrate consumes plan task queue state through
8
8
  `agentera prime --context orchestrate --format json` before raw
9
9
  artifact access, then updates status (pending -> complete/blocked) only
10
- when resolving a task.
10
+ when resolving a task. Failed evaluator results are recorded through the
11
+ retry-safe typed `record-evaluation` mutation before retry or blocking.
11
12
  2:
12
13
  id: A2
13
14
  artifact_id: progress
@@ -4,17 +4,18 @@ ARTIFACTS:
4
4
  artifact_id: plan
5
5
  local_role: produces_and_consumes
6
6
  description: >-
7
- Active plan with tasks, dependencies, and behavioral acceptance criteria.
8
- Plan writes this during the planning session and may read existing
9
- plan context before replacing or refining it.
7
+ Current plan with tasks, dependencies, and behavioral acceptance criteria.
8
+ Its active position is derived from the docs-mapped current-plan path,
9
+ not persisted lifecycle status. Plan writes this during the planning
10
+ session and may read existing plan context before replacing or refining it.
10
11
  2:
11
12
  id: A2
12
13
  artifact_id: plan_archive
13
14
  local_role: produces
14
15
  description: >-
15
- Created when a plan is fully
16
- executed or explicitly discarded by the user. Preserved for historical
17
- reference.
16
+ Immutable, non-executable history created when a plan is complete or
17
+ explicitly force-archived. Forced archival preserves an unfinished
18
+ plan's open status rather than claiming completion.
18
19
  3:
19
20
  id: A3
20
21
  artifact_id: vision
@@ -1,6 +1,6 @@
1
1
  # Plan Artifact Schema
2
2
  #
3
- # Active work plan maintained by plan. Each plan captures what will be built,
3
+ # Current work plan maintained by plan. Each plan captures what will be built,
4
4
  # why, constraints, scope boundaries, design approach, tasks with dependencies
5
5
  # and acceptance criteria, overall acceptance, and surprises.
6
6
  #
@@ -13,7 +13,7 @@
13
13
  # ─────────────────────────────────────────────────────────────────────
14
14
  # <!-- Level: light/full --> HEADER.level PL1
15
15
  # <!-- Created: date --> HEADER.created PL2
16
- # <!-- Status: active/completed --> HEADER.status PL3
16
+ # <!-- Status: active/completed --> HEADER.status PL3 (normalized)
17
17
  # <!-- Reviewed: date --> HEADER.reviewed PL4
18
18
  # <!-- Critic issues: N found... --> HEADER.critic_issues PL5
19
19
  # <!-- Revised: description --> HEADER.revised PL6
@@ -32,6 +32,8 @@
32
32
  # **Acceptance**: <criteria list> TASK.acceptance PL19
33
33
  # ## Overall Acceptance PLAN.overall_acceptance PL20
34
34
  # ## Surprises PLAN.surprises PL21
35
+ # ## Unknowns UNKNOWN.entry PU1
36
+ # ## Rejected Review Findings REJECTED.entry PR1
35
37
  #
36
38
  # Protocol references:
37
39
  # status visual tokens: VT1-VT4 (protocol.yaml VISUAL_TOKENS)
@@ -55,6 +57,8 @@ GROUP_PREFIXES:
55
57
  PLAN: PL
56
58
  SCOPE: PS
57
59
  TASK: PT
60
+ UNKNOWN: PU
61
+ REJECTED: PR
58
62
  VALIDATION: PV
59
63
 
60
64
  BUDGET:
@@ -99,10 +103,10 @@ HEADER:
99
103
  type: string
100
104
  required: true
101
105
  description: >-
102
- Plan lifecycle status. Active plans are being executed; complete
103
- plans are candidates for archival.
106
+ Canonical plan lifecycle. Positional activity is derived from the
107
+ plan's location and is not persisted.
104
108
  validation:
105
- - "Must be one of: active, complete"
109
+ - "Must be one of: open, complete"
106
110
  4:
107
111
  id: PH4
108
112
  field: reviewed
@@ -201,6 +205,62 @@ PLAN:
201
205
  Path to the previous active plan archived when this plan was created.
202
206
  Preserves plan lineage without changing lifecycle status.
203
207
 
208
+ UNKNOWN:
209
+ 1:
210
+ id: PU1
211
+ field: entry
212
+ type: map
213
+ required: true
214
+ description: >-
215
+ A planning-time question that can change whether downstream work remains
216
+ necessary as written. Full plans require at least one entry.
217
+ min_count: 1
218
+ 2:
219
+ id: PU2
220
+ field: question
221
+ parent: UNKNOWN.entry
222
+ type: string
223
+ required: true
224
+ description: "The unresolved planning-time question."
225
+ 3:
226
+ id: PU3
227
+ field: affects_task
228
+ parent: UNKNOWN.entry
229
+ type: integer
230
+ required: true
231
+ description: "The task number whose scope depends on the answer."
232
+ 4:
233
+ id: PU4
234
+ field: resolve_by
235
+ parent: UNKNOWN.entry
236
+ type: string
237
+ required: true
238
+ description: "How the affected task will resolve the question."
239
+
240
+ REJECTED:
241
+ 1:
242
+ id: PR1
243
+ field: entry
244
+ type: map
245
+ required: true
246
+ description: >-
247
+ A dismissed adversarial-review finding preserved with its rationale.
248
+ min_count: 1
249
+ 2:
250
+ id: PR2
251
+ field: issue
252
+ parent: REJECTED.entry
253
+ type: string
254
+ required: true
255
+ description: "The critic finding that was dismissed."
256
+ 3:
257
+ id: PR3
258
+ field: rationale
259
+ parent: REJECTED.entry
260
+ type: string
261
+ required: true
262
+ description: "Why the finding was dismissed rather than addressed."
263
+
204
264
  SCOPE:
205
265
  1:
206
266
  id: PS11
@@ -278,6 +338,15 @@ TASK:
278
338
  Acceptance criteria for this task. Each entry is a GIVEN/WHEN/THEN
279
339
  statement that must hold for the task to be considered complete.
280
340
  Required for full-level plans.
341
+ 6:
342
+ id: PT20
343
+ field: evaluation
344
+ type: mapping
345
+ required: false
346
+ description: >-
347
+ CLI-owned evaluator state written only by `agentera state plan
348
+ record-evaluation`. It records attempt and failure counts, the latest
349
+ verdict, retained failure evidence, and stable attempt provenance.
281
350
 
282
351
  VALIDATION:
283
352
  1:
@@ -300,7 +369,7 @@ VALIDATION:
300
369
  checks:
301
370
  - "level is present and is 'light' or 'full'"
302
371
  - "created is present and matches YYYY-MM-DD"
303
- - "status is present and is 'active' or 'completed'"
372
+ - "status is present and is 'open' or 'complete'"
304
373
  - "title is present and non-empty"
305
374
  - "what is present and non-empty"
306
375
  - "why is present and non-empty"
@@ -340,3 +409,186 @@ VALIDATION:
340
409
  checks:
341
410
  - "Per-task word count <= 100"
342
411
  - "Total file word count <= 2500"
412
+
413
+ LIFECYCLE_CONTRACT:
414
+ authority: this schema
415
+ canonical:
416
+ persisted_status:
417
+ field: header.status
418
+ values:
419
+ - open
420
+ - complete
421
+ meaning:
422
+ open: Work is unfinished, whether the plan is current or archived.
423
+ complete: Every task is complete.
424
+ position:
425
+ active: The plan occupies the docs-mapped current-plan path.
426
+ archived: The plan occupies the sibling archive directory.
427
+ persisted: false
428
+ execution:
429
+ eligible: Only a plan at the current-plan path can supply executable work.
430
+ archived: An archived plan is historical and non-executable regardless of status.
431
+ forced_archive:
432
+ unfinished_status: open
433
+ effect: Move the plan to immutable history without claiming completion.
434
+ compatibility:
435
+ legacy_read_window:
436
+ scope: >-
437
+ Read normalization and typed-writer canonicalization of plan-level
438
+ active to open and completed to complete for artifacts produced by
439
+ pre-canonical Agentera versions at the docs-mapped current-plan path
440
+ or its sibling archive directory.
441
+ writers: Canonical writers and migrators must emit only open or complete.
442
+ removal_condition: >-
443
+ Remove normalization only after the deterministic migration covers
444
+ current plans, archives, fixtures, and bundled upgrade inputs, and
445
+ regression tests prove no supported producer can emit a legacy value.
446
+ test_boundary:
447
+ - current plan with active normalizes to open and reports legacy input
448
+ - archived plan with active normalizes to open and remains non-executable
449
+ - completed normalizes to complete only at the plan-level compatibility seam
450
+ - canonical writers reject active and completed after migration support lands
451
+ - typed writes canonicalize a legacy current plan before publication
452
+ external_consumers:
453
+ evidence: >-
454
+ No shipped SDK, adapter, or package reads header.status directly;
455
+ supported consumers use the CLI plan discovery and state contracts.
456
+ commitment: No compatibility window is provided for direct YAML consumers.
457
+ inventory:
458
+ method: >-
459
+ Classification is pattern-based and enforced by a bounded repository
460
+ scan. Every file under scan.roots containing a discovery marker must
461
+ match at least one family pattern unless an explicit exclusion applies.
462
+ scan:
463
+ roots:
464
+ - .
465
+ symlinks: Excluded because their targets may leave the repository boundary.
466
+ excluded_directory_names:
467
+ names:
468
+ - .git
469
+ - node_modules
470
+ - .pnpm-store
471
+ - .venv
472
+ - .pytest_cache
473
+ - .ruff_cache
474
+ - .cache
475
+ - .snapshots
476
+ - __pycache__
477
+ - dist
478
+ - build
479
+ - coverage
480
+ - bundle
481
+ - .astro
482
+ - .svelte-kit
483
+ - .wrangler
484
+ reason: >-
485
+ Directory-name pruning prevents traversal of VCS metadata, vendor
486
+ dependencies, environments, caches, snapshots, bytecode, and generated
487
+ build or publication outputs at any repository depth.
488
+ markers:
489
+ - planDocumentParts
490
+ - discoverPlanArtifacts
491
+ - resolvePlanTaskEvidence
492
+ - header.status
493
+ - previous_plan_archived
494
+ - plan_archive
495
+ - state plan
496
+ - .agentera/plan.yaml
497
+ - plan.yaml
498
+ - state.plan.
499
+ - artifact_id: plan
500
+ - artifact: plan
501
+ - active plan
502
+ - archived plan
503
+ - plan lifecycle
504
+ exclusions:
505
+ - patterns: [.git, .git/**]
506
+ reason: Git object and worktree metadata is not a repository contract surface.
507
+ - patterns: [node_modules, node_modules/**, "**/node_modules", "**/node_modules/**"]
508
+ reason: Installed third-party dependencies are vendor content.
509
+ - patterns: [.pnpm-store, .pnpm-store/**, .venv, .venv/**]
510
+ reason: Package and Python environments are external dependency caches.
511
+ - patterns: [.pytest_cache, .pytest_cache/**, .ruff_cache, .ruff_cache/**]
512
+ reason: Tool caches are generated and carry no product contract.
513
+ - patterns: ["**/.cache", "**/.cache/**", .snapshots, .snapshots/**]
514
+ reason: Caches and filesystem snapshots are generated or external state.
515
+ - patterns: ["**/dist", "**/dist/**", "**/build", "**/build/**", "**/coverage", "**/coverage/**"]
516
+ reason: Compiled, bundled, and coverage outputs are generated from classified sources.
517
+ - patterns: [packages/cli/bundle, packages/cli/bundle/**, "**/.astro", "**/.astro/**", "**/.svelte-kit", "**/.svelte-kit/**"]
518
+ reason: Runtime bundles and framework outputs are generated publication artifacts.
519
+ - patterns: [.wrangler, .wrangler/**, "**/.wrangler", "**/.wrangler/**", "*.tgz", "**/*.tgz"]
520
+ reason: Deployment outputs and package tarballs are generated publication artifacts.
521
+ - patterns: [.env, .env.*, "**/.env", "**/.env.*", "*.pem", "**/*.pem", "*.key", "**/*.key"]
522
+ reason: Local secret files are neither read nor classified by repository contract tests.
523
+ - patterns:
524
+ - references/adapters/runtime-lifecycle-*.yaml
525
+ - packages/cli/src/runtime/lifecycle*.ts
526
+ - packages/cli/src/upgrade/lifecycle*.ts
527
+ - packages/cli/test/runtime/lifecycle*.test.ts
528
+ - packages/cli/test/upgrade/lifecycle*.test.ts
529
+ - packages/cli/test/cli/lifecycle*.test.ts
530
+ - packages/cli/test/validate/lifecycle*.test.ts
531
+ reason: These surfaces govern runtime installation lifecycle, not plan artifact lifecycle.
532
+ readers:
533
+ - src/**
534
+ - hooks/**
535
+ - .opencode/plugins/**/*.js
536
+ - packages/cli/src/cli/plan*.ts
537
+ - packages/cli/src/cli/orientation.ts
538
+ - packages/cli/src/cli/appContext.ts
539
+ - packages/cli/src/cli/commands/state/plan.ts
540
+ - packages/cli/src/cli/commands/prime/*.ts
541
+ - packages/cli/src/cli/capabilityContext/*.ts
542
+ - packages/cli/src/cli/contracts/orientationState.ts
543
+ - packages/cli/src/cli/startupCompletenessContract.ts
544
+ - packages/cli/src/hooks/sessionStart.ts
545
+ - packages/cli/src/eval/evalSkills.ts
546
+ writers:
547
+ - packages/cli/src/state/write/*.ts
548
+ - packages/cli/src/cli/commands/state/write.ts
549
+ migrators:
550
+ - packages/cli/src/upgrade/migrateArtifacts*.ts
551
+ - packages/cli/src/upgrade/upgradeOrchestrator.ts
552
+ - packages/cli/src/upgrade/doctor.ts
553
+ - packages/cli/src/cli/commands/prime/v1Migration.ts
554
+ schemas:
555
+ - skills/agentera/schemas/artifacts/*.yaml
556
+ - skills/agentera/capabilities/*/schemas/*.yaml
557
+ - skills/agentera/capability_schema_contract.yaml
558
+ adapters:
559
+ - references/**/*.yaml
560
+ - packages/cli/src/registries/*.ts
561
+ - packages/cli/src/state/startupAnalysis/*.ts
562
+ - packages/cli/src/cli/commands/schema.ts
563
+ - packages/cli/src/cli/commands/validate.ts
564
+ - packages/cli/src/cli/help.ts
565
+ - packages/cli/src/cli/prime-blob.ts
566
+ - packages/cli/src/hooks/validateArtifact/*.ts
567
+ - packages/cli/src/validate/selfAudit.ts
568
+ - packages/cli/src/hooks/compaction/*.ts
569
+ - packages/cli/src/cli/dispatch/*.ts
570
+ - .agentera/docs.yaml
571
+ - scripts/**
572
+ fixtures:
573
+ - packages/cli/test/**/*.ts
574
+ - packages/cli/test/**/*.md
575
+ - packages/cli/test/fixtures/**
576
+ - packages/cli/test/fixtures/**/.agentera/*
577
+ - packages/cli/test/upgrade/fixtures/**
578
+ - packages/cli/test/upgrade/fixtures/**/.agentera/*
579
+ - packages/cli/test/cli/fixtures/**
580
+ - tests/**
581
+ - fixtures/**
582
+ - .agentera/**
583
+ documented_external_commitments:
584
+ - packages/cli/src/capabilities/*/instructions.ts
585
+ - skills/agentera/SKILL.md
586
+ - skills/agentera/agents/*
587
+ - skills/agentera/references/*
588
+ - references/**/*.md
589
+ - docs/**
590
+ - packages/web/src/**
591
+ - "*.md"
592
+ - AGENTS.md
593
+ - README.md
594
+ - UPGRADE.md
@@ -1,5 +1,10 @@
1
1
  // Capability instructions for orchestrate
2
2
  // Served via `agentera prime --context orchestrate --format json`. RFC 2119 modal vocab.
3
3
  export const instructions = JSON.parse(String.raw `"# ORCHESTRATE\n\n**Orchestration Runtime: Knowledge-coordinated Execution Strategy, Targeted Routing. Evaluate, Resolve, Adapt.**\n\nGlyph: ⎈ (protocol ref: SG12).\n\nA meta-orchestrator that delegates capabilities as subagents, evaluates each task with audit, and loops through plans until work is done. The thin orchestrator: reads plans, routes tasks, gates quality. Never touches code. All creativity happens in delegated capabilities; orchestrate follows a deterministic state machine.\n\nEach invocation = one orchestration session. Multiple plan cycles within a single session. In orchestrate only, \u0060dispatch\u0060 and \u0060chain\u0060 are autonomous verbs inside the approved orchestration flow; \u0060suggest\u0060 waits for user confirmation before invoking.\n\n---\n\n## State artifacts\n\nOrchestrate produces no new artifact files. It reads and updates existing artifacts. Normal startup begins from \u0060agentera prime --context orchestrate --format json\u0060.\n\nTrust \u0060orchestration_context.source_contract\u0060. When \u0060complete_for_orchestration_context\u0060 is true, the context is authoritative — no raw plan, progress, health, TODO, or decisions reads for task selection or evaluator handoff. When incomplete, run listed fallback commands before any raw artifact read. Raw reads are last-resort diagnostics, not normal startup.\n\nThe \u0060agentera\u0060 CLI is a state interface. Do not run capability-name commands such as \u0060agentera build\u0060 or \u0060agentera plan\u0060.\n\n| Artifact | Role | Purpose |\n|----------|------|---------|\n| \u0060plan\u0060 | produces_and_consumes | Task queue. Use \u0060orchestration_context.task_queue\u0060 and \u0060selected_next_task\u0060; update status (pending → complete/blocked) only after evaluation. |\n| \u0060progress\u0060 | consumes | Cross-cycle context. Use \u0060orchestration_context.progress_verification\u0060; dispatched capabilities write their own entries. |\n| \u0060health\u0060 | consumes | Health context after plan completion to decide whether to start a new plan. |\n| \u0060todo\u0060 | produces | Blocked task logging. Write when a task exhausts its retry budget. |\n| \u0060decisions\u0060 | consumes | Decision context. Use included caveats or \u0060agentera state decisions --format json\u0060; preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060. |\n| \u0060vision\u0060 | consumes | Direction context for bootstrap. If missing from context, treat as a caveat. |\n| \u0060profile\u0060 | consumes | Persona context. Preserve stale or missing caveats; do not refresh profile during orchestration. |\n| \u0060docs\u0060 | consumes | Artifact path resolution for write targets. |\n\n### Decision satisfaction authority\n\nWhen orchestration touches decision satisfaction, agents may mark provisional satisfaction with evidence only. Orchestrate MUST NOT mark, infer, or user-confirm final satisfaction; only the user confirms final satisfaction. If decisions are compacted, missing satisfaction state, open, provisional, or review-needed, preserve the caveat and review pressure in dispatch and evaluation context.\n\nVisual tokens: \u0060skills/agentera/protocol.yaml\u0060 (task states VT1-VT4, glyph SG12, exit signals EX1-EX4, severity SI1-SI4, decision labels DL1-DL3).\n\n---\n\n## The orchestration loop\n\nThe orchestrator follows a deterministic state machine. It does not reason creatively about orchestration; it follows the loop.\n\n### Step 0: Assess\n\nStart from \u0060agentera prime --context orchestrate --format json\u0060. Check \u0060orchestration_context.source_contract\u0060, the returned plan summary, and \u0060state_presence\u0060 before considering raw artifacts.\n\n- **No plan in returned state**: bootstrap mode. Delegate to research for vision-gap analysis, then plan for plan creation. If the vision artifact is also absent or caveated, suggest ⛥ vision first and wait for user confirmation.\n- **Plan exists, \u0060header.status: complete\u0060, and all tasks complete**: completed-plan closure. Run the staleness check, archive the plan, then spawn audit for a health check. If clean, chain research then plan for the next plan cycle. Include lineage, staleness findings, health issues, and source-contract caveats as context.\n- **Plan exists, but blocked or incomplete tasks remain**: do not archive it as successful completion. Route to the orchestration loop or replanning so incomplete evidence stays visible.\n- **Plan exists, tasks pending**: proceed to the loop using \u0060orchestration_context\u0060 task selection.\n\n**Staleness check** (plan completion): When all tasks are complete, check whether delegated capabilities updated their expected artifacts.\n\n1. **Identify delegated capabilities** from plan task history and progress summary in CLI context.\n2. **Compare modification dates**: for each expected artifact, check \u0060git log -1 --format=%aI -- <path>\u0060 against the plan's creation date. An artifact is stale if it was not modified since the plan's creation and the owning capability was delegated at least once during the plan.\n3. **Surface findings**: include stale artifact findings as informational context for the next plan cycle. Archive the plan with \u0060agentera state plan archive --format json\u0060. The writer owns immutable archive naming and active-plan removal.\n\n---\n\nStep markers: display \u0060── task N · step M/5: verb\u0060 before each step in the loop. N is the task number from the selected orchestration context task.\n\n### Step 1: Select task\n\nUse \u0060orchestration_context.selected_next_task\u0060 when present. Otherwise, use \u0060orchestration_context.task_queue.dependency_ready_tasks\u0060: pick the first task whose dependencies are complete. Treat \u0060orchestration_context.task_queue.blocked_tasks[*].blocked_reasons\u0060 as the dependency explanation.\n\nIf no tasks are eligible (all remaining tasks are blocked by incomplete dependencies), report \u0060stuck\u0060 with the dependency chain.\n\nUse decision state or caveats from the returned context first. If decisions are missing from startup context, run \u0060agentera state decisions --format json\u0060. Preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 in dispatch and evaluation context instead of filling gaps by reconstruction.\n\n### Step 2: Delegate\n\nInfer which capability handles the task based on its description:\n\n| Task signals | Target capability |\n|--------------|-------------------|\n| Implementation, building, coding, feature, fix, refactor | ⧉ build |\n| Documentation, docs, README, CHANGELOG | ▤ document |\n| Health audit, architecture review, code quality check | ⛶ audit |\n| Research, external patterns, library evaluation | ⬚ research |\n| Optimization, performance, metric improvement, benchmark | ⎘ optimize |\n| Visual identity, design tokens, DESIGN.md | ◰ design |\n| Version bump | ⧉ build (with bump instructions from docs artifact) |\n\nIf the task does not clearly map, default to ⧉ build.\n\nSpawn the target capability through the runtime-native subagent substrate. Do not run capability-name CLI commands; the \u0060agentera\u0060 CLI remains a state interface.\n\n\u0060\u0060\u0060\nYou are executing a planned task for [project].\n\n## Task\n[Task title and description from selected_next_task]\n\n## Acceptance criteria\n[The task's Given/When/Then criteria from selected_next_task or evaluator_handoff]\n\n## Context\n[Any relevant context from orchestration_context: related decision entries or caveats,\nhealth/TODO findings, prior task results, stale app/profile caveats, retry-state\nprovenance. Keep brief.]\n\n## Constraints\n- Execute ONLY this task. No scope creep.\n- Follow existing code patterns and conventions.\n- Use the runtime-native subagent descriptor or Task surface for the selected capability.\n- Commit your changes with a conventional commit message.\n- You are working on a plan-driven task. Update the task status in the plan artifact\n to ■ complete when done.\n\u0060\u0060\u0060\n\nWait for the task-notification result.\n\n### Step 3: Evaluate\n\nEvaluation has two surfaces in sequence: an orchestrator-side presence check using latest progress verification, then an audit delegation whose prompt is extended with an evidence audit. Both surfaces must run before the task can be resolved.\n\n**Surface 1: Presence check from progress verification**\n\nWhen the delegated capability was build (or any capability that produces progress cycle entries), perform a cheap evidence presence check before spawning audit:\n\n1. Start with \u0060orchestration_context.progress_verification\u0060 and its \u0060latest_progress_verification_pointer\u0060.\n2. If unavailable or incomplete, run \u0060agentera state progress --format json\u0060 before any raw artifact read.\n3. Look for a non-empty \u0060verified\u0060 field in the latest relevant progress entry.\n4. **Present and non-empty**: proceed to Surface 2.\n5. **Missing or empty**: treat the task as a failed evaluation. Go straight into Step 4's FAIL branch with \"missing or empty \u0060verified\u0060 field in progress Cycle N\" as the failure reason.\n\n**Surface 2: Audit delegation with evidence audit**\n\nOnce the presence check passes, spawn audit as a subagent to verify the work:\n\n\u0060\u0060\u0060\nYou are evaluating a completed task for [project].\n\n## Task that was completed\n[Task title and description from evaluator_handoff]\n\n## Acceptance criteria to verify\n[The task's Given/When/Then criteria from evaluator_handoff]\n\n## What to check\n- Verify each acceptance criterion against the current codebase state.\n- Check for unintended side effects from the implementation.\n- Verify the project's test/build suite still passes.\n\n## Verification evidence audit\n- Use the latest progress verification pointer and \u0060verified\u0060 evidence supplied by\n the orchestration context or \u0060agentera state progress --format json\u0060.\n- Compare the recorded evidence to the task's acceptance criteria.\n- Report whether the evidence substantiates the criteria or is merely trivially\n populated (e.g., \"tests pass\" without any observation of the actual feature\n running counts as insufficient).\n- If the field is \u0060N/A: <tag>\u0060, confirm the tag is drawn from the allowlist\n (\u0060docs-only\u0060, \u0060refactor-no-behavior-change\u0060, \u0060chore-dep-bump\u0060,\n \u0060chore-build-config\u0060, \u0060test-only\u0060) AND that the tag fits the nature of the work.\n- If the field is a free-form N/A rationale, confirm it is at least 8 words long AND\n actually explains why the change has no observable behavior.\n- Flag the task as FAIL on the evidence audit if the recorded \u0060verified\u0060 content\n does not substantiate the acceptance criteria.\n\n## Source-contract caveats to preserve\n- Include compacted decision caveats, stale health/profile/app caveats, missing\n state-family caveats, and retry-state provenance exactly as supplied.\n- Do not treat missing retry attempts as an attempt count. If status is\n \u0060not_recorded\u0060 or \u0060unavailable\u0060, keep that status in the evaluation report.\n\n## Output format\nFor each acceptance criterion, report:\n- status: PASS or FAIL\n- evidence: what you checked and what you found\n- citation: \u0060<file>:<line>\u0060 OR \u0060not-applicable: <reason>\u0060 — **required for every FAIL row**\n- verify_command: exact \u0060grep\u0060 or \u0060git show\u0060 invocation — **required for every FAIL row\n with a file:line citation**; the command must reproduce the evidence at the cited line\n\nUse \u0060orchestration_context.evaluator_handoff.output_requirements\u0060 from prime context as\nthe machine-readable citation contract. FAIL rows without a valid citation are incomplete\nand must be treated as evaluation failures.\n\nThen report the verification evidence audit outcome (PASS or FAIL with reasoning).\n\nThen give an overall verdict: PASS (all criteria met and evidence audit passed) or FAIL\n(any criterion failed or evidence audit failed).\n\u0060\u0060\u0060\n\nWait for the audit verdict.\n\n### Step 4: Resolve\n\nBased on audit's verdict:\n\n**PASS**: Mark the task \u0060■ complete\u0060 (VT1) in the plan artifact (if the delegated capability did not already do so). Proceed to Step 5.\n\n**FAIL (retries < 2)**: Increment the retry count. Re-delegate to the same capability with audit's findings as additional context:\n\n\u0060\u0060\u0060\nYou are retrying a task that failed evaluation for [project].\n\n## Original task\n[Task title and description]\n\n## Acceptance criteria\n[The task's Given/When/Then criteria]\n\n## Evaluation findings (what failed)\n[Audit's failure report with evidence]\n\n## What to fix\nAddress each failure point. All acceptance criteria must pass on re-evaluation.\n\u0060\u0060\u0060\n\nReturn to Step 3.\n\n**FAIL (retries = 2)**: The task has exhausted its retry budget. Mark the task \u0060▨ blocked\u0060 (VT4) in the plan artifact. Log the failure to TODO.md with audit's findings as context. Proceed to Step 5.\n\nWhen writing to the plan artifact or TODO.md, use the task identity and caveats from \u0060orchestration_context\u0060. Do not refresh installed app/profile state, edit the vision artifact, or invent retry attempt counts.\n\n### Step 5: Log and loop\n\nCheck the plan state:\n\n- **More pending tasks with satisfied dependencies?** Return to Step 1.\n- **All tasks complete?** Return to Step 0 for completed-plan closure.\n- **Complete + blocked or incomplete tasks?** Keep the plan active and route to replanning or TODO logging; do not archive as successful completion.\n- **Context approaching budget limit?** Stop the session, report current progress.\n- **User interrupt?** Stop the session, report current progress.\n\n---\n\n## Safety rails\n\n<critical>\n\n- MUST NOT read implementation source code. The orchestrator delegates; it does not implement. Artifact files (\u0060.agentera/*.yaml\u0060, \u0060TODO.md\u0060) are state records, not source code; raw reads are last-resort after CLI context and listed fallback commands.\n- MUST NOT run tests, builds, linters, or implementation project commands directly. Delegated capabilities handle all verification.\n- MUST NOT modify the vision artifact. The orchestrator reads direction; it does not set it.\n- MUST NOT delegate to a capability without an active plan task justifying it (except during bootstrap in Step 0).\n- MUST NOT push to any remote. Local operations only.\n- MUST NOT retry a task more than 2 times. After the second failure, mark blocked and move on.\n- MUST NOT skip evaluation. Every completed task must be verified by audit before being marked complete.\n- MUST NOT make implementation decisions. Delegate to the appropriate capability.\n- MUST NOT write to progress, changelog, or other capability-owned artifacts. Dispatched capabilities write their own entries. Orchestrate changes plan lifecycle state only through \u0060agentera state plan set-status ...\u0060 and \u0060agentera state plan archive\u0060.\n- MUST NOT research external patterns or libraries. Delegate to research.\n- MUST NOT mark, infer, or user-confirm final decision satisfaction. Only the user confirms. Preserve caveats for missing, compacted, open, provisional, or review-needed satisfaction state.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⎈ orchestrate · <status>\u0060 on its own line, followed by a summary sentence. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what needs attention.\n\n- **complete** (EX1): All plan tasks are complete, the health check passed, and the session concluded with all planned work finished.\n- **flagged** (EX2): The plan was executed but with issues: one or more tasks were blocked after exhausting retries, or the post-plan health check revealed problems. Each concern is listed explicitly.\n- **stuck** (EX3): Cannot proceed because the plan has circular dependencies preventing any task from becoming eligible, no target capabilities are available to delegate, or file access prevents reading or updating artifacts.\n- **waiting** (EX4): No plan exists and the bootstrap chain cannot proceed because the vision artifact is absent and the user has not confirmed how to create one, or a delegated capability returned \u0060waiting\u0060 status requiring user input.\n\n### Loop stop condition\n\nEach task gets max 2 retries before being blocked. Additionally, if 3 consecutive different tasks all fail evaluation (even after their retries), orchestrate stops the session and escalates:\n\n1. **Stop**: do not delegate more tasks.\n2. **Log**: file the pattern to TODO.md with what was attempted across the 3 tasks and what appears systematically wrong.\n3. **Surface**: tell the user and recommend a course of action (e.g., \"⛶ audit for a full audit\", \"❈ discuss to reconsider the plan\", \"the plan may need replanning via ≡ plan\").\n\n---\n\n## Cross-capability integration\n\nOrchestrate is the orchestration layer that chains all other capabilities together. Each active runtime provides its registry-declared subagent substrate: OpenCode: \u0060OpenCode .opencode/agents single primary agent (D73)\u0060; Codex CLI: \u0060Codex ~/.codex/agents TOML descriptors\u0060; Cursor IDE and cursor-agent are one Cursor identity: \u0060Cursor .cursor/agents single agent descriptor (D73)\u0060; Copilot CLI: \u0060Copilot CLI host-managed dispatch\u0060. Orchestrator-side instructions, retry logic, and audit evaluation gating stay unchanged across runtimes; only the concrete delegation surface differs.\n\n### Delegation targets\n\n- **⧉ build**: Implementation, feature, fix, refactor tasks. Build runs its full cycle as a subagent and writes progress and changelog entries.\n- **⛶ audit**: Two roles — evaluator after each task completion (verifying acceptance criteria), and health checker after plan completion (producing health grades). Audit is the discriminator in the evaluate-then-proceed pattern.\n- **▤ document**: Documentation tasks — docs updates, README changes, documentation coverage.\n- **⬚ research**: Research tasks. During bootstrap, orchestrate chains research for vision-gap analysis before plan creates a plan.\n- **⎘ optimize**: Optimization-shaped tasks (metric improvement, performance tuning) route to optimize.\n- **◰ design**: Visual identity tasks (DESIGN.md updates, design token changes).\n- **≡ plan**: When no plan exists or the current plan is complete, orchestrate invokes plan to create the next plan.\n\n### State consumers\n\n- **❈ discuss**: Decision state provides firm constraints during task selection. Preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 from returned decision entries.\n- **⛺ vision**: Direction context during bootstrap. If vision is missing, preserve the caveat and ask before creating direction.\n- **♾ profile**: Persona context for calibrating delegation. Do not refresh profile state during orchestration; if unavailable, proceed without persona grounding and preserve the caveat.\n\n### When to use orchestrate\n\nExecute an existing plan: create the plan first (\u0060/agentera plan\u0060), then run \u0060/agentera orchestrate\u0060 to execute it with evaluation gating.\n\nFull autonomous session: \u0060/agentera orchestrate\u0060 with no plan triggers bootstrap (research → plan → execute).\n\nAfter a deliberation: \u0060/agentera discuss\u0060 → \u0060/agentera plan\u0060 → \u0060/agentera orchestrate\u0060.\n\nUse orchestrate instead of a host loop for plan-aware, evaluated, multi-cycle execution. Use it when the user explicitly requests autonomous multi-task execution.\n"`);
4
- export default instructions;
4
+ export default `${instructions}
5
+
6
+ ## Evaluation Retry State
7
+
8
+ After every evaluator verdict, persist it with \`agentera state plan record-evaluation --task N --attempt-id ID --verdict {pass,fail} --provenance SOURCE --format json\`. A failed verdict also requires \`--failure-evidence\`. Reuse the same stable attempt ID after an interrupted retry; the writer owns attempt counts, retains the latest failure evidence and provenance, and blocks the task after its second failed evaluation. Do not reconstruct retry state from conversation memory or modify decision satisfaction.
9
+ `;
5
10
  //# sourceMappingURL=instructions.js.map
@@ -1 +1 @@
1
- {"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/orchestrate/instructions.ts"],"names":[],"mappings":"AAAA,0CAA0C;AAC1C,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,gpnBAAgpnB,CAAC,CAAC;AAC3snB,eAAe,YAAY,CAAC"}
1
+ {"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/orchestrate/instructions.ts"],"names":[],"mappings":"AAAA,0CAA0C;AAC1C,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,gpnBAAgpnB,CAAC,CAAC;AAC3snB,eAAe,GAAG,YAAY;;;;;CAK7B,CAAC"}
@@ -1,6 +1,6 @@
1
1
  // Source: skills/agentera/capabilities/plan/instructions.md (relocated D65)
2
2
  // Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
3
3
  // equivalence with the deleted file (whitespace allowed to differ at line endings only).
4
- export const instructions = JSON.parse(String.raw `"# PLAN\n\n**Planning Logic: Behavioral Requirements Decomposition. Enumerate, Refine, Assign**\n\nGlyph: **≡** (protocol ref: SG5). Scale-adaptive planning bridging deliberation and execution. PLAN artifact with behavioral acceptance criteria for build. Plan owns WHAT and WHY; build owns HOW. Three levels: skip (trivial work, route directly to build), light (single-cycle), full (multi-cycle with adversarial review).\n\nVoice: adopt the conversational voice declared in the project's vision artifact \u0060identity.voice\u0060 field when available — do not improvise a separate personality. In Create mode before a vision exists, use a neutral operational stance: describe behavior, not personality.\n\n---\n\n## State artifacts\n\nOne write target and one archive directory in \u0060.agentera/\u0060.\n\n| Artifact | Role | Source |\n|---|---|---|\n| \u0060plan\u0060 | produces_and_consumes | \u0060.agentera/plan.yaml\u0060 (or docs-mapped path) |\n| \u0060plan_archive\u0060 | produces | \u0060.agentera/archive/plan-{date}.yaml\u0060 |\n| \u0060vision\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060decisions\u0060 | consumes | firm (DL1) entries via \u0060agentera state decisions --format json\u0060 |\n| \u0060todo\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060health\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060progress\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060profile\u0060 | consumes | \u0060planning_context.profile.path\u0060 |\n| \u0060docs\u0060 | consumes | docs artifact mapping for path overrides and versioning block |\n\n**Read contract for PLAN artifact consumers**: tasks carry status from the \u0060status\u0060 enum (\u0060pending\u0060, \u0060in_progress\u0060, \u0060complete\u0060, \u0060skipped\u0060); surprises and unknowns land in their respective top-level lists. When all tasks are \u0060complete\u0060, the planner (or build at cycle closeout) runs \u0060agentera state plan archive --format json\u0060. The writer owns immutable archive naming, crash-consistent closeout, and active-plan removal. The full consumption flow lives in build's and orchestrate's own instructions; plan declares only what the artifact shape guarantees.\n\n**Startup contract**: trust \u0060planning_context.startup_contract\u0060 and \u0060raw_artifact_read_policy\u0060 from \u0060agentera prime --context plan --format json\u0060. When \u0060source_contract.complete_for_plan_artifact\u0060 is true, \u0060agentera state plan --format json\u0060 already serves summary, tasks, dependencies, acceptance, evidence, surprises, unknowns, and previous-plan archive references — do not reread the persisted artifact defensively. Raw plan artifact access is for writing, archiving, validation, corruption diagnostics, or after CLI fallbacks fail. The runtime owns the planning-level taxonomy, required step list, step-marker format, max full-plan tasks, cli-first-orientation policy, artifact access boundaries, and handoff expectations — do not re-encode them here. Artifact path resolution is owned by SKILL.md; visual-token families by \u0060skills/agentera/protocol.yaml\u0060.\n\nDirect invocation of ≡ plan on an already-complete plan: archiving before writing its replacement is implicit in the direct invocation and does not require separate pre-write confirmation. Human-initiated replacement plans still require plan approval before the write. Replacing, discarding, or archiving an active or incomplete plan is not implicit; ask for explicit confirmation.\n\n---\n\n## Workflow phases\n\nMode-split shape: Step 0 detects level (skip/light/full), then the mode-specific steps run. Step labels — orient, specify, review, audit, write, handoff — are owned by \u0060planning_context.startup_contract.required_steps\u0060; the runtime owns the step-marker format.\n\n### Step 0: Detect level\n\nAssess work complexity. Read the description (user, \u0060decisions\u0060 artifact, or \u0060todo\u0060 artifact). Scan codebase if needed.\n\n| Signal | Level |\n|---|---|\n| Single-file change, localized defect fix, or config tweak **and** touches no shared abstraction | **Skip** |\n| One module affected, clear scope, fits one build cycle | **Light** |\n| Multiple modules, multi-file changes, 3+ logical steps, new feature spanning architecture | **Full** |\n\n**Skip**: This doesn't need a plan. Suggest ⧉ build and wait for confirmation unless the user already asked to implement now. Stop here.\n\n**Light or Full**: Proceed to planning.\n\nIf uncertain between light and full, default to light.\n\n### Step 1: Orient\n\nTrust \u0060planning_context\u0060 from \u0060agentera prime --context plan --format json\u0060 and read state families by name (\u0060plan\u0060, \u0060vision\u0060, \u0060decisions\u0060, \u0060todo\u0060, \u0060health\u0060, \u0060progress\u0060, \u0060docs\u0060, \u0060profile\u0060). Use listed \u0060fallback_commands\u0060 for missing families before any last-resort raw artifact read.\n\n- **vision**: the north star (if present)\n- **decisions**: firm (DL1) entries are hard constraints for planning. Read via \u0060agentera state decisions --format json\u0060 and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n- **health**: latest codebase health grades (if present)\n- **todo**: related known issues (if present)\n- **progress**: what was built recently (if present)\n- **profile**: served via \u0060planning_context.profile.path\u0060 — read directly when \u0060status: loaded\u0060; if missing or stale, proceed without persona grounding. Staleness is a caveat, not approval to refresh profile state.\n\n**Project discovery** (if unfamiliar with the repo): map directory structure, read README.md and AGENTS.md, dependency manifests, identify build/test/lint commands.\n\nBefore decomposing: summarize the constraints from \u0060vision\u0060 and \u0060decisions\u0060.\n\n### Step 2: Specify\n\nDefine WHAT and WHY. Intent layer, not implementation details.\n\n#### Light plans\n\nBrief conversation (2-3 questions):\n\n- **What**: one-paragraph description of the change\n- **Why**: what value it delivers or what problem it solves\n- **Constraints**: what must NOT break, what's out of scope\n- **Acceptance criteria**: 3-5 behavioral criteria in Given/When/Then format\n\nWrite PLAN. Present for approval (human-initiated) or proceed (autonomous).\n\n#### Full plans\n\nDeeper conversation:\n\n- **What**: detailed description\n- **Why**: motivation, user impact, relationship to \u0060vision\u0060\n- **Constraints**: architectural boundaries, off-limits modules\n- **Scope**: what's in, out, deferred\n- **Design**: approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure; those belong in scope or task-level acceptance. Design SHOULD describe how subsystems interrelate and the order phases SHOULD run in.\n- **Task decomposition**: 3-8 ordered tasks, each one build cycle. Per task: description, dependencies, 3-5 behavioral Given/When/Then acceptance criteria\n- **Test proportionality**: for tasks with tests, add a proportionality target. Default: one pass + one fail per testable unit. Override only with explicit rationale.\n- **Plan-level current-state check**: every full plan ends with a final state sync task depending on all prior tasks.\n- **Version bump check**: add a bump task when the \u0060docs\u0060 artifact \u0060versioning\u0060 block exists and the plan includes \u0060feat\u0060/\u0060fix\u0060 work.\n- **Fog identification**: every full plan surfaces at least one known-unknown — a planning-time question whose answer determines whether downstream tasks are still needed as written. Each unknown lists the question, the task it affects, and how the answer resolves (\u0060resolve_by\u0060).\n- **Overall acceptance criteria**: behavioral criteria for the complete feature\n\nPresent for approval or proceed to adversarial review.\n\n### Step 3: Review (full plans only)\n\nSpawn an adversarial critic. The critic MUST find issues.\n\n\u0060\u0060\u0060\nYou are reviewing a development plan for [project]. Your job is to find problems.\n\n## The plan\n[Full PLAN artifact content]\n\n## Your mandate\nYou MUST identify at least one issue. \"Looks good\" is not acceptable.\n\nLook for:\n- Tasks too large for a single implementation cycle\n- Missing dependencies between tasks\n- Acceptance criteria too vague to verify\n- Acceptance criteria that leak implementation details\n- Scope gaps or scope creep\n- Ordering issues\n- Conflicting constraints\n- Unacknowledged risks\n- Fog treated as resolved\n\u0060\u0060\u0060\n\nAddress legitimate issues; dismiss false positives with rationale. Record each dismissal in the artifact's \u0060rejected:\u0060 list with the issue text and the rationale, so downstream consumers (build, orchestrate, audit) inherit the adjudication rather than relitigating.\n\nPresent reviewed plan.\n\n### Step 4: Pre-write self-audit\n\nRun the pre-write lint per \u0060planning_context.startup_contract.pre_write_self_audit_required\u0060. The capability-instruction contract owns the command shape (dispatch to \u0060agentera check lint\u0060 with the plan draft). The check inspects the draft for verbosity overruns, abstraction creep, and filler accumulation. Max 3 revision attempts. Flag with \u0060[post-audit-flagged]\u0060 if still failing.\n\n### Step 5: Write PLAN\n\nWrite tasks with acceptance criteria. The conversation preserves reasoning; the artifact preserves the plan.\n\nSave the approved complete plan document to temporary YAML/JSON input and run \u0060agentera state plan create --input PATH --format json\u0060 (or \u0060--input -\u0060). The writer validates it, archives a complete predecessor, injects lineage, and publishes to the docs-mapped path. Replacing an incomplete predecessor requires the approved \u0060--force\u0060 override.\n\n#### Light plan format\n\n\u0060\u0060\u0060yaml\nheader:\n level: light\n created: YYYY-MM-DD\n status: active\n title: Short Title\nwhat: One paragraph.\nwhy: Motivation and value.\nconstraints: What must not break; what is out of scope.\noverall_acceptance:\n - GIVEN context WHEN action THEN expected outcome\ntasks: []\n\u0060\u0060\u0060\n\n#### Full plan format\n\n\u0060\u0060\u0060yaml\nheader:\n level: full\n created: YYYY-MM-DD\n status: active\n reviewed: YYYY-MM-DD\n critic_issues: \"N found, N addressed, N dismissed\"\n title: Short Title\nwhat: Detailed description.\nwhy: Motivation, user impact, relationship to vision.\nconstraints: Architectural boundaries and off-limits modules.\noverall_acceptance:\n - GIVEN context WHEN action THEN expected outcome\nscope:\n included: []\n excluded: []\n deferred: []\ndesign: Approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure.\nunknowns:\n - question: \"Will X support Y in task 2's environment?\"\n affects_task: 3\n resolve_by: \"Build cycle 2 outcome; if X fails, task 3 becomes a refactor scope\"\nrejected:\n - issue: \"Acceptance criterion on task 4 references a specific library\"\n rationale: \"Library name is the test-fixture contract, not implementation guidance — kept.\"\ntasks:\n - number: 1\n name: Title\n depends_on: []\n status: pending\n acceptance:\n - GIVEN context WHEN action THEN expected outcome\nsurprises: []\n\u0060\u0060\u0060\n\n### Step 6: Handoff\n\n- **Single-task plan**: suggest ⧉ build to execute and wait for confirmation.\n- **Full plan**: suggest ⎈ orchestrate to execute the entire plan and wait for confirmation.\n\nIf \u0060unknowns:\u0060 lists fog at planning time, name the foreshadow in the handoff: \"Build will resolve unknowns; re-invoke ≡ plan if surprises on one task alter the acceptance criteria of downstream tasks.\"\n\n---\n\n## Safety rails\n\n<critical>\n- Plan MUST NOT include implementation details in the PLAN artifact. Plan owns WHAT and WHY; build owns HOW.\n- Plan MUST NOT write acceptance criteria that reference implementation. Use behavioral, domain-language criteria only.\n- Plan MUST NOT produce more than 8 tasks in a full plan. If work requires more, split it into sequential plans.\n- Plan MUST NOT modify the PLAN artifact during a build cycle except to update task status and add surprises.\n- Plan MUST NOT skip adversarial review for full plans.\n- Plan MUST NOT auto-approve plans when human-initiated. Present for approval.\n- Plan MUST NOT plan trivial work. If skip level, say so and route to build.\n- Plan MUST NOT invoke build, optimize, or orchestrate without the user's explicit consent. Suggest, don't dispatch.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion.\n\nFormat: \u0060─── ≡ plan · <status> ───\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060, \u0060stuck\u0060, and \u0060waiting\u0060, add a ▸ bullet below the summary identifying what needs attention.\n\n- **complete**: PLAN artifact written and approved, adversarial review ran for full plans, handoff suggested.\n- **flagged**: Plan produced with caveats — critic issues dismissed rather than resolved, scope larger than ideal, acceptance criteria not fully behavioral, or planning-time unknowns still open at handoff.\n- **stuck**: Cannot plan because the work description is too ambiguous to decompose, required context artifacts contradict, or the user declined to approve the plan with no clear revision path.\n- **waiting**: The feature or change is not specified with enough detail to produce acceptance criteria, or key architectural constraints are unknown and cannot be inferred from the codebase.\n\n---\n\n## Cross-capability integration\n\nPlan is the bridge between deliberation and execution.\n\n### Fed by ❈ discuss\n\nWhen discuss's deliberation concludes with a decision to build, plan is the next step. The \u0060decisions\u0060 artifact carries the \"why\" context as hard constraints.\n\n### Feeds ⧉ build\n\nPLAN tasks become build's work queue. Task acceptance criteria become cycle exit conditions. Build updates task status and logs surprises. The read contract is declared in §2; build's consumption flow lives in build's instructions.\n\n### Feeds ⎘ optimize\n\nWhen a plan includes optimization-shaped tasks (measurable changes with apply/rollback semantics), those tasks delegate to optimize.\n\n### Informed by ⛶ audit\n\n\u0060health\u0060 findings can trigger remediation plans. Audit reveals structural issues; plan produces a plan to address them.\n\n### Informed by ♾ profile\n\nDecision profile calibrates planning depth and pattern preferences.\n\n### Informed by ⬚ research\n\nWhen research recommends patterns or libraries, plan incorporates them into the plan's design section.\n\n### Reads ⛥ vision\n\n\u0060vision\u0060 provides the north star read during Orient.\n\n### Fed by ▤ document (docs-first workflow)\n\nIn the docs-first workflow, document writes intent docs first, then plan decomposes them into tasks.\n\n### Reads ▤ document versioning\n\nPlan reads the \u0060versioning\u0060 block from the \u0060docs\u0060 artifact. When the plan includes \u0060feat\u0060/\u0060fix\u0060 work, plan appends a version bump task.\n\n### Getting started\n\n**Planning a new feature**: ❈ discuss → ≡ plan → ⧉ build or ⎈ orchestrate.\n\n**Planning a remediation**: ⛶ audit → ≡ plan → ⧉ build.\n\n**Mid-feature replanning**: when surprises logged on one task alter the acceptance criteria of downstream tasks, re-invoke ≡ plan to reassess. Read the surprises, surface new unknowns, archive or amend, then resume ⧉ build. If surprises are isolated and acceptance criteria of downstream tasks remain intact, build can continue without replanning.\n\n**Skipping the plan**: trivial work (skip level) routes to ⧉ build directly.\n"`);
4
+ export const instructions = JSON.parse(String.raw `"# PLAN\n\n**Planning Logic: Behavioral Requirements Decomposition. Enumerate, Refine, Assign**\n\nGlyph: **≡** (protocol ref: SG5). Scale-adaptive planning bridging deliberation and execution. PLAN artifact with behavioral acceptance criteria for build. Plan owns WHAT and WHY; build owns HOW. Three levels: skip (trivial work, route directly to build), light (single-cycle), full (multi-cycle with adversarial review).\n\nVoice: adopt the conversational voice declared in the project's vision artifact \u0060identity.voice\u0060 field when available — do not improvise a separate personality. In Create mode before a vision exists, use a neutral operational stance: describe behavior, not personality.\n\n---\n\n## State artifacts\n\nOne write target and one archive directory in \u0060.agentera/\u0060.\n\n| Artifact | Role | Source |\n|---|---|---|\n| \u0060plan\u0060 | produces_and_consumes | \u0060.agentera/plan.yaml\u0060 (or docs-mapped path) |\n| \u0060plan_archive\u0060 | produces | \u0060.agentera/archive/plan-{date}.yaml\u0060 |\n| \u0060vision\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060decisions\u0060 | consumes | firm (DL1) entries via \u0060agentera state decisions --format json\u0060 |\n| \u0060todo\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060health\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060progress\u0060 | consumes | \u0060planning_context\u0060 family |\n| \u0060profile\u0060 | consumes | \u0060planning_context.profile.path\u0060 |\n| \u0060docs\u0060 | consumes | docs artifact mapping for path overrides and versioning block |\n\n**Read contract for PLAN artifact consumers**: tasks carry status from the \u0060status\u0060 enum (\u0060pending\u0060, \u0060in_progress\u0060, \u0060complete\u0060, \u0060skipped\u0060); surprises and unknowns land in their respective top-level lists. When all tasks are \u0060complete\u0060, the planner (or build at cycle closeout) runs \u0060agentera state plan archive --format json\u0060. The writer owns immutable archive naming, crash-consistent closeout, and active-plan removal. The full consumption flow lives in build's and orchestrate's own instructions; plan declares only what the artifact shape guarantees.\n\n**Startup contract**: trust \u0060planning_context.startup_contract\u0060 and \u0060raw_artifact_read_policy\u0060 from \u0060agentera prime --context plan --format json\u0060. When \u0060source_contract.complete_for_plan_artifact\u0060 is true, \u0060agentera state plan --format json\u0060 already serves summary, tasks, dependencies, acceptance, evidence, surprises, unknowns, and previous-plan archive references — do not reread the persisted artifact defensively. Raw plan artifact access is for writing, archiving, validation, corruption diagnostics, or after CLI fallbacks fail. The runtime owns the planning-level taxonomy, required step list, step-marker format, max full-plan tasks, cli-first-orientation policy, artifact access boundaries, and handoff expectations — do not re-encode them here. Artifact path resolution is owned by SKILL.md; visual-token families by \u0060skills/agentera/protocol.yaml\u0060.\n\nDirect invocation of ≡ plan on an already-complete plan: archiving before writing its replacement is implicit in the direct invocation and does not require separate pre-write confirmation. Human-initiated replacement plans still require plan approval before the write. Replacing, discarding, or archiving an active or incomplete plan is not implicit; ask for explicit confirmation.\n\n---\n\n## Workflow phases\n\nMode-split shape: Step 0 detects level (skip/light/full), then the mode-specific steps run. Step labels — orient, specify, review, audit, write, handoff — are owned by \u0060planning_context.startup_contract.required_steps\u0060; the runtime owns the step-marker format.\n\n### Step 0: Detect level\n\nAssess work complexity. Read the description (user, \u0060decisions\u0060 artifact, or \u0060todo\u0060 artifact). Scan codebase if needed.\n\n| Signal | Level |\n|---|---|\n| Single-file change, localized defect fix, or config tweak **and** touches no shared abstraction | **Skip** |\n| One module affected, clear scope, fits one build cycle | **Light** |\n| Multiple modules, multi-file changes, 3+ logical steps, new feature spanning architecture | **Full** |\n\n**Skip**: This doesn't need a plan. Suggest ⧉ build and wait for confirmation unless the user already asked to implement now. Stop here.\n\n**Light or Full**: Proceed to planning.\n\nIf uncertain between light and full, default to light.\n\n### Step 1: Orient\n\nTrust \u0060planning_context\u0060 from \u0060agentera prime --context plan --format json\u0060 and read state families by name (\u0060plan\u0060, \u0060vision\u0060, \u0060decisions\u0060, \u0060todo\u0060, \u0060health\u0060, \u0060progress\u0060, \u0060docs\u0060, \u0060profile\u0060). Use listed \u0060fallback_commands\u0060 for missing families before any last-resort raw artifact read.\n\n- **vision**: the north star (if present)\n- **decisions**: firm (DL1) entries are hard constraints for planning. Read via \u0060agentera state decisions --format json\u0060 and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n- **health**: latest codebase health grades (if present)\n- **todo**: related known issues (if present)\n- **progress**: what was built recently (if present)\n- **profile**: served via \u0060planning_context.profile.path\u0060 — read directly when \u0060status: loaded\u0060; if missing or stale, proceed without persona grounding. Staleness is a caveat, not approval to refresh profile state.\n\n**Project discovery** (if unfamiliar with the repo): map directory structure, read README.md and AGENTS.md, dependency manifests, identify build/test/lint commands.\n\nBefore decomposing: summarize the constraints from \u0060vision\u0060 and \u0060decisions\u0060.\n\n### Step 2: Specify\n\nDefine WHAT and WHY. Intent layer, not implementation details.\n\n#### Light plans\n\nBrief conversation (2-3 questions):\n\n- **What**: one-paragraph description of the change\n- **Why**: what value it delivers or what problem it solves\n- **Constraints**: what must NOT break, what's out of scope\n- **Acceptance criteria**: 3-5 behavioral criteria in Given/When/Then format\n\nWrite PLAN. Present for approval (human-initiated) or proceed (autonomous).\n\n#### Full plans\n\nDeeper conversation:\n\n- **What**: detailed description\n- **Why**: motivation, user impact, relationship to \u0060vision\u0060\n- **Constraints**: architectural boundaries, off-limits modules\n- **Scope**: what's in, out, deferred\n- **Design**: approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure; those belong in scope or task-level acceptance. Design SHOULD describe how subsystems interrelate and the order phases SHOULD run in.\n- **Task decomposition**: 3-8 ordered tasks, each one build cycle. Per task: description, dependencies, 3-5 behavioral Given/When/Then acceptance criteria\n- **Test proportionality**: for tasks with tests, add a proportionality target. Default: one pass + one fail per testable unit. Override only with explicit rationale.\n- **Plan-level current-state check**: every full plan ends with a final state sync task depending on all prior tasks.\n- **Version bump check**: add a bump task when the \u0060docs\u0060 artifact \u0060versioning\u0060 block exists and the plan includes \u0060feat\u0060/\u0060fix\u0060 work.\n- **Fog identification**: every full plan surfaces at least one known-unknown — a planning-time question whose answer determines whether downstream tasks are still needed as written. Each unknown lists the question, the task it affects, and how the answer resolves (\u0060resolve_by\u0060).\n- **Overall acceptance criteria**: behavioral criteria for the complete feature\n\nPresent for approval or proceed to adversarial review.\n\n### Step 3: Review (full plans only)\n\nSpawn an adversarial critic. The critic MUST find issues.\n\n\u0060\u0060\u0060\nYou are reviewing a development plan for [project]. Your job is to find problems.\n\n## The plan\n[Full PLAN artifact content]\n\n## Your mandate\nYou MUST identify at least one issue. \"Looks good\" is not acceptable.\n\nLook for:\n- Tasks too large for a single implementation cycle\n- Missing dependencies between tasks\n- Acceptance criteria too vague to verify\n- Acceptance criteria that leak implementation details\n- Scope gaps or scope creep\n- Ordering issues\n- Conflicting constraints\n- Unacknowledged risks\n- Fog treated as resolved\n\u0060\u0060\u0060\n\nAddress legitimate issues; dismiss false positives with rationale. Record each dismissal in the artifact's \u0060rejected:\u0060 list with the issue text and the rationale, so downstream consumers (build, orchestrate, audit) inherit the adjudication rather than relitigating.\n\nPresent reviewed plan.\n\n### Step 4: Validate and publish\n\nOptionally run \u0060agentera check lint --artifact plan --file PATH --strict --format json\u0060 for early draft feedback. The typed writer is the sole publication gate: it validates strict prose lint and schema against the final candidate before publishing.\n\nSave the approved complete plan document to temporary YAML/JSON input and run \u0060agentera state plan create --input PATH --format json\u0060 (or \u0060--input -\u0060). The writer validates the final bytes, archives a complete predecessor, injects lineage, and publishes to the docs-mapped path. Replacing an incomplete predecessor requires the approved \u0060--force\u0060 override.\n\n#### Light plan format\n\n\u0060\u0060\u0060yaml\nheader:\n level: light\n created: 2026-07-13\n status: open\n title: \"Plan: Short Title\"\nwhat: Deliver one bounded outcome.\nwhy: Keep the work ready for one build cycle.\nconstraints: Preserve the stated delivery boundary.\noverall_acceptance: GIVEN the plan is published WHEN build reads it THEN the next task is clear.\nscope:\n included: [bounded outcome]\n excluded: [unrelated work]\ntasks:\n - number: 1\n name: Deliver outcome\n depends_on: []\n status: pending\n acceptance:\n - GIVEN the work is complete WHEN behavior is checked THEN the outcome is available.\nsurprises: []\n\u0060\u0060\u0060\n\n#### Full plan format\n\nOmit \u0060rejected:\u0060 when no critic finding is dismissed; never write an empty \u0060rejected: []\u0060 section.\n\n\u0060\u0060\u0060yaml\nheader:\n level: full\n created: 2026-07-13\n status: open\n reviewed: 2026-07-13\n critic_issues: \"1 found, 0 addressed, 1 dismissed\"\n title: \"Plan: Short Title\"\nwhat: Deliver a validated multi-task outcome.\nwhy: Keep dependent work behaviorally ordered.\nconstraints: Preserve the stated delivery boundary.\noverall_acceptance: GIVEN all tasks complete WHEN the plan is evaluated THEN the intended outcome is available.\nscope:\n included: [validated outcome]\n excluded: [unrelated work]\n deferred: []\ndesign: Sequence observable outcomes without prescribing implementation.\nunknowns:\n - question: \"Will the dependent outcome remain necessary after task 1?\"\n affects_task: 2\n resolve_by: \"Use task 1 evidence before beginning task 2.\"\nrejected:\n - issue: \"Specify an implementation library in task acceptance.\"\n rationale: \"Behavioral acceptance remains implementation-independent.\"\ntasks:\n - number: 1\n name: Establish outcome\n depends_on: []\n status: pending\n acceptance:\n - GIVEN the first task completes WHEN behavior is checked THEN its outcome is available.\n - number: 2\n name: Verify dependent outcome\n depends_on: [\"1\"]\n status: pending\n acceptance:\n - GIVEN task 1 completes WHEN the dependent behavior is checked THEN its outcome is available.\nsurprises: []\n\u0060\u0060\u0060\n\n### Step 5: Handoff\n\n- **Single-task plan**: suggest ⧉ build to execute and wait for confirmation.\n- **Full plan**: suggest ⎈ orchestrate to execute the entire plan and wait for confirmation.\n\nIf \u0060unknowns:\u0060 lists fog at planning time, name the foreshadow in the handoff: \"Build will resolve unknowns; re-invoke ≡ plan if surprises on one task alter the acceptance criteria of downstream tasks.\"\n\n---\n\n## Safety rails\n\n<critical>\n- Plan MUST NOT include implementation details in the PLAN artifact. Plan owns WHAT and WHY; build owns HOW.\n- Plan MUST NOT write acceptance criteria that reference implementation. Use behavioral, domain-language criteria only.\n- Plan MUST NOT produce more than 8 tasks in a full plan. If work requires more, split it into sequential plans.\n- Plan MUST NOT modify the PLAN artifact during a build cycle except to update task status and add surprises.\n- Plan MUST NOT skip adversarial review for full plans.\n- Plan MUST NOT auto-approve plans when human-initiated. Present for approval.\n- Plan MUST NOT plan trivial work. If skip level, say so and route to build.\n- Plan MUST NOT invoke build, optimize, or orchestrate without the user's explicit consent. Suggest, don't dispatch.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion.\n\nFormat: \u0060─── ≡ plan · <status> ───\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060, \u0060stuck\u0060, and \u0060waiting\u0060, add a ▸ bullet below the summary identifying what needs attention.\n\n- **complete**: PLAN artifact written and approved, adversarial review ran for full plans, handoff suggested.\n- **flagged**: Plan produced with caveats — critic issues dismissed rather than resolved, scope larger than ideal, acceptance criteria not fully behavioral, or planning-time unknowns still open at handoff.\n- **stuck**: Cannot plan because the work description is too ambiguous to decompose, required context artifacts contradict, or the user declined to approve the plan with no clear revision path.\n- **waiting**: The feature or change is not specified with enough detail to produce acceptance criteria, or key architectural constraints are unknown and cannot be inferred from the codebase.\n\n---\n\n## Cross-capability integration\n\nPlan is the bridge between deliberation and execution.\n\n### Fed by ❈ discuss\n\nWhen discuss's deliberation concludes with a decision to build, plan is the next step. The \u0060decisions\u0060 artifact carries the \"why\" context as hard constraints.\n\n### Feeds ⧉ build\n\nPLAN tasks become build's work queue. Task acceptance criteria become cycle exit conditions. Build updates task status and logs surprises. The read contract is declared in §2; build's consumption flow lives in build's instructions.\n\n### Feeds ⎘ optimize\n\nWhen a plan includes optimization-shaped tasks (measurable changes with apply/rollback semantics), those tasks delegate to optimize.\n\n### Informed by ⛶ audit\n\n\u0060health\u0060 findings can trigger remediation plans. Audit reveals structural issues; plan produces a plan to address them.\n\n### Informed by ♾ profile\n\nDecision profile calibrates planning depth and pattern preferences.\n\n### Informed by ⬚ research\n\nWhen research recommends patterns or libraries, plan incorporates them into the plan's design section.\n\n### Reads ⛥ vision\n\n\u0060vision\u0060 provides the north star read during Orient.\n\n### Fed by ▤ document (docs-first workflow)\n\nIn the docs-first workflow, document writes intent docs first, then plan decomposes them into tasks.\n\n### Reads ▤ document versioning\n\nPlan reads the \u0060versioning\u0060 block from the \u0060docs\u0060 artifact. When the plan includes \u0060feat\u0060/\u0060fix\u0060 work, plan appends a version bump task.\n\n### Getting started\n\n**Planning a new feature**: ❈ discuss → ≡ plan → ⧉ build or ⎈ orchestrate.\n\n**Planning a remediation**: ⛶ audit → ≡ plan → ⧉ build.\n\n**Mid-feature replanning**: when surprises logged on one task alter the acceptance criteria of downstream tasks, re-invoke ≡ plan to reassess. Read the surprises, surface new unknowns, archive or amend, then resume ⧉ build. If surprises are isolated and acceptance criteria of downstream tasks remain intact, build can continue without replanning.\n\n**Skipping the plan**: trivial work (skip level) routes to ⧉ build directly.\n"`);
5
5
  export default instructions;
6
6
  //# sourceMappingURL=instructions.js.map
@@ -1 +1 @@
1
- {"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/plan/instructions.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,0qfAA0qf,CAAC,CAAC;AACruf,eAAe,YAAY,CAAC"}
1
+ {"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/plan/instructions.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,omgBAAomgB,CAAC,CAAC;AAC/pgB,eAAe,YAAY,CAAC"}