@amsterdamdatalabs/adl-agent-control-linux-x64 0.1.35 → 0.1.46

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 (128) hide show
  1. package/bin/adl +2 -2
  2. package/bin/reconcile +3 -11
  3. package/bin/setup +15 -15
  4. package/package.json +1 -1
  5. package/packages/agent-hooks/deploy-profile.json +1 -1
  6. package/packages/agent-hooks/package.json +1 -1
  7. package/packages/agent-hooks/src/main.ts +23 -2
  8. package/packages/agent-hooks/src/pre-tool-use/handler.ts +2 -2
  9. package/packages/agent-hooks/src/rules/impl/adl-build-run-role.ts +116 -0
  10. package/packages/agent-hooks/src/rules/impl/adl-git-user-override-block.ts +159 -0
  11. package/packages/agent-hooks/src/rules/impl/adl-mcp-cli.ts +22 -12
  12. package/packages/agent-hooks/src/rules/impl/adl-pr-complete-pending.ts +9 -9
  13. package/packages/agent-hooks/src/rules/impl/adl-pr-role.ts +6 -5
  14. package/packages/agent-hooks/src/rules/impl/adl-run-required.ts +11 -5
  15. package/packages/agent-hooks/src/rules/impl/adl-workitem-role.ts +18 -5
  16. package/packages/agent-hooks/src/rules/impl/agent-tamper-protection.ts +30 -25
  17. package/packages/agent-hooks/src/rules/impl/git-core.ts +4 -8
  18. package/packages/agent-hooks/src/rules/impl/git-target.ts +5 -0
  19. package/packages/agent-hooks/src/rules/impl/mcp-tool.ts +4 -2
  20. package/packages/agent-hooks/src/rules/impl/tool-frontend.ts +230 -11
  21. package/packages/agent-hooks/src/rules/registry.ts +11 -2
  22. package/packages/agent-hooks/src/rules/shell/git-identity.ts +1 -1
  23. package/packages/agent-hooks/src/rules/shell/invocation.ts +14 -2
  24. package/packages/agent-hooks/src/rules/shell/protected-carriers.ts +10 -7
  25. package/packages/agent-settings/assets/TARUN-GLOBAL-AGENTS-INSTRUCTIONS.md +2 -2
  26. package/packages/agent-settings/package.json +1 -1
  27. package/packages/agent-settings/src/deploy/agents-deploy.ts +19 -1
  28. package/packages/agent-settings/src/deploy/index.ts +1 -0
  29. package/packages/agent-skills/assets/agent-search-tool-audit/SKILL.md +4 -6
  30. package/packages/agent-skills/assets/code-review/SKILL.md +84 -66
  31. package/packages/agent-skills/assets/diagnosing-bugs/SKILL.md +23 -2
  32. package/packages/agent-skills/assets/diagnosing-bugs/references/FEEDBACK-LOOP-TACTICS.md +1 -1
  33. package/packages/agent-skills/assets/explore-codebase/SKILL.md +3 -2
  34. package/packages/agent-skills/assets/finalize-feature/SKILL.md +63 -0
  35. package/packages/agent-skills/assets/fix-ci/SKILL.md +58 -0
  36. package/packages/agent-skills/assets/handoff/SKILL.md +1 -1
  37. package/packages/agent-skills/assets/implement-feature/SKILL.md +150 -0
  38. package/packages/agent-skills/assets/implement-feature/references/briefs.md +94 -0
  39. package/packages/agent-skills/assets/implement-item/SKILL.md +71 -0
  40. package/packages/agent-skills/assets/mechanics/SKILL.md +38 -0
  41. package/packages/agent-skills/assets/plan-feature/SKILL.md +141 -0
  42. package/packages/agent-skills/assets/prepare-promotion/SKILL.md +90 -0
  43. package/packages/agent-skills/assets/ralplan/SKILL.md +149 -0
  44. package/packages/agent-skills/assets/refactor-safely/SKILL.md +4 -3
  45. package/packages/agent-skills/assets/report-bug/SKILL.md +72 -0
  46. package/packages/agent-skills/assets/review-change/SKILL.md +82 -0
  47. package/packages/agent-skills/assets/review-plan/SKILL.md +124 -0
  48. package/packages/agent-skills/assets/triage-workitems/SKILL.md +99 -0
  49. package/packages/agent-skills/assets/ultragoal/SKILL.md +77 -0
  50. package/packages/agent-skills/assets/validate-design/SKILL.md +64 -0
  51. package/packages/agent-skills/assets/verify-item/SKILL.md +71 -0
  52. package/packages/agent-skills/assets/wayfinder/SKILL.md +1 -1
  53. package/packages/agent-skills/assets/workitems-process/SKILL.md +145 -0
  54. package/packages/agent-skills/assets/workitems-process/references/ado-and-git.md +227 -0
  55. package/packages/agent-skills/assets/workitems-process/references/evidence.md +74 -0
  56. package/packages/agent-skills/assets/workitems-process/references/workitem-states.md +92 -0
  57. package/packages/agent-skills/assets/write-feature/SKILL.md +94 -0
  58. package/packages/agent-skills/dist/deploy.d.ts +52 -0
  59. package/packages/agent-skills/dist/deploy.d.ts.map +1 -1
  60. package/packages/agent-skills/dist/deploy.js +218 -7
  61. package/packages/agent-skills/dist/deploy.js.map +1 -1
  62. package/packages/agent-skills/dist/index.d.ts +1 -1
  63. package/packages/agent-skills/dist/index.d.ts.map +1 -1
  64. package/packages/agent-skills/dist/index.js +1 -1
  65. package/packages/agent-skills/dist/index.js.map +1 -1
  66. package/packages/agent-skills/package.json +1 -1
  67. package/packages/agent-skills/src/deploy.ts +288 -6
  68. package/packages/agent-skills/src/index.ts +10 -1
  69. package/packages/azdo/README.md +13 -4
  70. package/packages/azdo/bunfig.toml +6 -0
  71. package/packages/azdo/package.json +1 -1
  72. package/packages/azdo/scripts/probe-ado-rules.ts +1 -1
  73. package/packages/azdo/src/activity-log.ts +118 -0
  74. package/packages/azdo/src/azdo-attachments.ts +109 -0
  75. package/packages/azdo/src/azdo-pl.ts +100 -3
  76. package/packages/azdo/src/azdo-pr.ts +376 -17
  77. package/packages/azdo/src/azdo-wit.ts +594 -34
  78. package/packages/azdo/src/cli.ts +119 -12
  79. package/packages/azdo/src/lib/client.ts +95 -17
  80. package/packages/azdo/src/lib/validate-pr-metadata.ts +14 -5
  81. package/packages/azdo/src/mcp-server.ts +121 -8
  82. package/packages/azdo/src/tool-dispatch.ts +107 -23
  83. package/packages/azdo/src/workflow-ladder.csv +125 -107
  84. package/packages/azdo/src/workflow-rules.ts +254 -97
  85. package/packages/fleet/src/install-adl-package.ts +4 -3
  86. package/packages/repo-controls/README.md +12 -4
  87. package/packages/repo-controls/assets/promote.ts +1 -0
  88. package/packages/repo-controls/assets/scaffold/docs/AGENTS.md +5 -5
  89. package/packages/repo-controls/assets/scaffold/plans/AGENTS.md +42 -13
  90. package/packages/repo-controls/assets/scaffold/root/CONTRIBUTING.md +5 -5
  91. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/closed_set/test_check.py +0 -11
  92. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/filename/test_check.py +4 -6
  93. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/ledger/test_check.py +15 -0
  94. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/docs-okf-profiles.yaml +1 -17
  95. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-profile-untyped/docs/research/no-type.md +1 -1
  96. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-profile-untyped/docs/research/typed-experiment.md +1 -1
  97. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-profile-untyped/docs/research/typed-research.md +1 -1
  98. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/extra-key.md +1 -1
  99. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/extra-keys.md +1 -1
  100. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/missing-created.md +1 -1
  101. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/missing-description.md +1 -1
  102. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/missing-last-update.md +1 -1
  103. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/missing-status.md +1 -1
  104. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/missing-title.md +1 -1
  105. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/optional-keys.md +1 -1
  106. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/fixtures/okf-research/docs/research/research-ok.md +1 -1
  107. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/docs/okf_profile/test_check.py +3 -22
  108. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/open_work_cap/check.py +39 -182
  109. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/open_work_cap/fixtures/open-work-cap-clean/plans/features/az601-clean/intent.md +17 -0
  110. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/open_work_cap/test_check.py +90 -321
  111. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plan_metadata.py +31 -5
  112. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/check.py +282 -54
  113. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-clean/plans/features/az347-test-coverage/design.md +35 -0
  114. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-clean/plans/features/az347-test-coverage/file-map-reference.md +19 -0
  115. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-clean/plans/features/az347-test-coverage/intent.md +25 -0
  116. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-clean/plans/features/az347-test-coverage/items/az351-restore-entrypoint.md +25 -0
  117. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-clean/plans/features/az347-test-coverage/requirements.md +44 -0
  118. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/fixtures/plans-layout-violation/plans/features/az347-test-coverage/requirements.md +44 -0
  119. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/checks/layout/plans_layout/test_check.py +646 -53
  120. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/cli.py +3 -3
  121. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/policy/docs_shape.py +1 -12
  122. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/policy/gate-registry.alt.yaml +1 -1
  123. package/packages/repo-controls/package/adl-compliance/src/adl_compliance/policy/gate-registry.yaml +1 -1
  124. package/packages/repo-controls/package.json +1 -1
  125. package/packages/repo-controls/src/config.ts +21 -2
  126. package/packages/repo-controls/src/doctor.ts +9 -14
  127. package/packages/repo-controls/src/findings-ratchet.ts +12 -0
  128. package/packages/repo-controls/src/hook.ts +61 -4
@@ -0,0 +1,77 @@
1
+ ---
2
+ name: ultragoal
3
+ description: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.
4
+ ---
5
+
6
+ # Ultragoal Workflow
7
+
8
+ ## When to use
9
+
10
+ Use for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.
11
+
12
+ ## Inputs and preconditions
13
+
14
+ - Durable artifacts are `.adw/ultragoal/brief.md`, `.adw/ultragoal/goals.json`, and `.adw/ultragoal/ledger.jsonl`.
15
+ - New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while ADW tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.
16
+ - Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.
17
+
18
+ ## Operational steps: create
19
+
20
+ Run one command, then inspect the generated plan:
21
+ ```bash
22
+ adw ultragoal create-goals --brief "<brief>"
23
+ adw ultragoal create-goals --brief-file <path>
24
+ cat <brief> | adw ultragoal create-goals --from-stdin
25
+ adw ultragoal create-goals --codex-goal-mode per-story --brief "<brief>"
26
+ ```
27
+ If refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.
28
+
29
+ ## Operational steps: execute
30
+
31
+ Repeat until `adw ultragoal status` reports all goals complete:
32
+
33
+ 1. Run `adw ultragoal complete-goals` and read its handoff.
34
+ 2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.
35
+ 3. Complete one ADW story and audit its objective against real artifacts and verification evidence.
36
+ 4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:
37
+ ```bash
38
+ adw ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --codex-goal-json <fresh-get-goal-json-or-path>
39
+ ```
40
+ 5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `adw ultragoal complete-goals --retry-failed`.
41
+ 6. On the final story, complete the final gate below before `update_goal({status: "complete"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.
42
+
43
+ ## Explicit steering
44
+
45
+ Use evidence-backed directives only when the decomposition must change:
46
+ ```bash
47
+ adw ultragoal steer --kind add_subgoal --title "<title>" --objective "<objective>" --evidence "<evidence>" --rationale "<reason>" --json
48
+ adw ultragoal steer --directive-json ./steering.json --json
49
+ ```
50
+ Supported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.
51
+
52
+ ## Phase/HUD handoff
53
+
54
+ At standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):
55
+ ```bash
56
+ adw state write --input '{"mode":"ultragoal","active":true,"current_phase":"planning"}' --json
57
+ ```
58
+ Inside Autopilot, keep the parent mode active and set `current_phase:"ultragoal"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.
59
+
60
+ ## Optional Team bridge
61
+
62
+ For parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.
63
+
64
+ ## Final gate and exit evidence
65
+
66
+ Before final completion:
67
+
68
+ 1. Run targeted story verification.
69
+ 2. Run `ai-slop-cleaner` on changed files, then rerun verification.
70
+ 3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.
71
+ 4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:
72
+ ```bash
73
+ adw ultragoal record-review-blockers --goal-id <id> --title "Resolve final code-review blockers" --objective "<objective>" --evidence "<findings>" --codex-goal-json <active-get-goal-json-or-path>
74
+ ```
75
+ 5. If clean, call `update_goal({status: "complete"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.
76
+
77
+ Report goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from ADW state alone.
@@ -0,0 +1,64 @@
1
+ ---
2
+ name: validate-design
3
+ description: Read-only check that a Feature's design.md still matches the repo - compare the Feature's baseline SHA with the worktree HEAD over the files and symbols design.md and file-map-reference.md name, and rule FRESH or DRIFT with the exact design delta. Use when the implementation lead spawns it at Design Validation, or again after mid-loop drift. requirements.md is not re-validated.
4
+ metadata:
5
+ step: "validate"
6
+ role: "architect"
7
+ states: "Design Validation"
8
+ ---
9
+
10
+ # Validate Design (sub-agent skill)
11
+
12
+ Load `workitems-process` first. You are a leaf sub-agent of `lead` (`implement-feature`). You check **`design.md` and its `file-map-reference.md`** against the repo. `requirements.md` was validated in planning and approved at G1; do not re-validate it. Drift never leaves the run: the lead sends a planner to update `design.md` and continues ([No block](../workitems-process/SKILL.md#no-block)). You never edit anything.
13
+
14
+ ## When to use
15
+
16
+ - Lead call 1: all items just moved Approved → Design Validation. Scope = the whole Feature.
17
+ - Lead call 2: after a planner updated `design.md` (re-check, once).
18
+ - Lead call 3: mid-loop drift (In Implementation → Design Validation **[pending F1]**). Scope = the item, seeded by the executor's `DRIFT` finding.
19
+ - **Not for Bugs.** A Fixes Bug has no `design.md` and no Design Validation state; its per-Bug run goes Approved → In Reproduction. If handed a Bug, return that and stop.
20
+
21
+ ## Inputs (from the brief)
22
+
23
+ - Plan folder `plans/features/az<id>-<slug>/`: `design.md`, `file-map-reference.md`; `BaselineSha` (the integration SHA the plan was written against); `against` = worktree `HEAD`; optional `scope` and seed finding. The run starts by merging the integration base into its branch, so the worktree `HEAD` contains the current integration: you diff `<BaselineSha>..HEAD` and record `head_sha`.
24
+
25
+ ## Preconditions
26
+
27
+ 1. Worktree toplevel equals the brief's worktree; the branch head is printed and recorded as `head_sha`.
28
+ 2. `<BaselineSha>` is an ancestor of `HEAD`. If not, return it to the lead as a finding and stop ([No block](../workitems-process/SKILL.md#no-block)).
29
+ 3. The tree is clean (you read a committed state).
30
+
31
+ ## Procedure
32
+
33
+ 1. **Collect the surface.** From `design.md` (`## Solution`, `## Decisions`, `## Verification`, `## Risks`, `## Docs impact`) and `file-map-reference.md`, list every file path, directory and symbol named (`FILES`, `DIRS`, `SYMBOLS`). Add the seed finding's `where` paths.
34
+ 2. **Measure change since baseline.** Diff the file set against `<BaselineSha>..HEAD`; the per-path rename and status view; the commit log over the surface. For each symbol, find it at `HEAD` and at `<BaselineSha>`; compare signatures.
35
+ 3. **Judge each design claim** (`file:line` refs, signatures, "X calls Y", chosen option, the AC → test map): still true at HEAD, or moved, renamed, removed, already done by someone else?
36
+ 4. **Classify.**
37
+
38
+ | Ruling | Condition |
39
+ |---|---|
40
+ | `FRESH` | No change to `FILES`/`SYMBOLS`, or changes provably irrelevant to every claim (say why per commit) |
41
+ | `DRIFT` | Something design.md names changed, and design.md can be corrected without changing any `AC-n`. Delta required |
42
+
43
+ Neither fits (a correct design would have to change an `AC-n` or the scope, or a named contract is gone): rule `DRIFT` with a separate finding that names the `AC-n` or scope; the lead's path for AC drift is in [No block](../workitems-process/SKILL.md#no-block).
44
+ 5. **Write findings.** `DRIFT`: one finding per design passage. `where` = design section + path (`Item az9002 › src/x.ts:40`); `what` = the commit(s) that moved it (`<sha7> <subject>`); `fix` = the exact replacement text. Severity low/medium.
45
+ 6. **Return the report** (format in `implement-feature` › `references/briefs.md`): `lane: validate`, `target`, `base_sha` = `BaselineSha`, `head_sha`, `verdict`, `findings`, `artifacts` (diff range, files in the surface, commands run).
46
+
47
+ ## Verdicts
48
+
49
+ | Verdict | Lead does |
50
+ |---|---|
51
+ | `FRESH` | Continues |
52
+ | `DRIFT` | Sends `planner` (design-update mode) with your delta, then asks you again once |
53
+
54
+ ## Stop rules
55
+
56
+ - One ruling per call, at the `head_sha` you recorded at start ([Evidence and reports](../workitems-process/SKILL.md#evidence-and-reports), the head rule). If HEAD moves while you work, finish against the one you recorded (diff `<BaselineSha>..<head_sha>`, not `..HEAD`) and say so; never stop or restart. The lead compares your `head_sha` with the branch head and re-runs you at the new head when it moved.
57
+ - Same tool failure twice: return it to the lead as a finding and stop ([No block](../workitems-process/SKILL.md#no-block)).
58
+
59
+ ## Never
60
+
61
+ - Never edit `design.md`, `requirements.md` or any file; never commit, push or move an item.
62
+ - Never rule `FRESH` without running the step 2 commands.
63
+ - Never fold an `AC-n` change into a `DRIFT` design delta; name it as its own finding (step 4).
64
+ - Never recommend sending items to New or In Planning.
@@ -0,0 +1,71 @@
1
+ ---
2
+ name: verify-item
3
+ description: Independently verify one item - or, in Feature-final mode, the whole Feature - at an exact head SHA against its EARS acceptance criteria and adversarial scenarios, read-only, in a fresh context. Use when the implementation lead spawns verifier for the In Testing step of an item, for the Feature-final check, or to re-check a CI-fix delta.
4
+ metadata:
5
+ step: "verify"
6
+ role: "verifier"
7
+ states: "In Testing"
8
+ ---
9
+
10
+ # Verify Item (sub-agent skill)
11
+
12
+ Load `workitems-process` first. You are a leaf sub-agent of `lead` (`implement-feature`). Prove or disprove that the head meets the criteria. Bounded adversarial QA, one pass, no fixing. The item loop is non-linear: you may be called for the same item again after a fix, at a new head.
13
+
14
+ ## When to use
15
+
16
+ | Mode | Scope |
17
+ |---|---|
18
+ | **item** | One item's `AC-n` list, at the head SHA the lead names. For a Bug the criteria are the Bug item file's `## Expected behaviour` (EARS) plus `## Behaviour that must not change` |
19
+ | **final** (Feature-final) | Every `AC-n` in `requirements.md`, the full suite, at the final head. In a per-Bug run the criteria are the Bug item file's `## Expected behaviour` (EARS) plus `## Behaviour that must not change`. This is the evidence the merge relies on |
20
+ | **delta** | After a CI fix: the changed paths plus the `AC-n` they touch, at the new head |
21
+
22
+ Not for fixing code or reviewing style.
23
+
24
+ ## Inputs (from the brief)
25
+
26
+ - Mode, item id (item/delta), the `AC-n` list with the item's `## Verification` lines, the head SHA, `base_sha` (for Bug proof: the integration SHA the per-Bug branch was created from).
27
+ - There is no PR yet in item and final modes: required checks are the repo's own commands, run locally. In delta mode the PR exists; read its failing check's job for what to re-run.
28
+
29
+ ## Preconditions
30
+
31
+ 1. The worktree toplevel equals the brief's worktree; else return it to the lead as a finding and stop ([No block](../workitems-process/SKILL.md#no-block)). Record the branch head as `head_sha` and finish against it ([Evidence and reports](../workitems-process/SKILL.md#evidence-and-reports), the head rule): if HEAD differs from the named head SHA, or moves during the run, run in an export of `head_sha` under `.scratchpad/`, say so in the report, and never stop or restart; the lead re-runs you at the new head.
32
+ 2. The tree is clean before you start.
33
+ 3. You are a fresh context. You never read the executor's transcript, only its committed work and the plan.
34
+
35
+ ## Procedure
36
+
37
+ 1. **Build the matrix** before running anything: scenario id, `AC-n` or risk it covers, setup, command, expected signal, actual result, cleanup. Every `AC-n` in scope gets at least one row.
38
+ 2. **Acceptance checks.** For each `AC-n` run the mapped test or command. Capture command, exit code and the line that proves the signal. An `AC-n` with no runnable check is a FAIL finding (`fix`: add the test), not a pass by reading. Final mode also runs the full suite, lint, typecheck and build.
39
+ 3. **Bug regression proof** (Bug items). You must not change HEAD in the shared worktree. Export the base into `.scratchpad/base/`; copy the regression test from head into it; run it and confirm it **fails for the reported defect**. Then run it at head and confirm it passes normally: at head it carries no expected-failure mark (the fix commit removes the mark the reproduce commit added); a mark left at head is a FAIL finding. If the exported copy cannot run the test, the proof is not PASS: FAIL with a finding naming what the copy lacks.
40
+ 4. **Adversarial scenarios** relevant to the change only:
41
+ - malformed input: missing fields, invalid flags, oversized or unusual-Unicode strings, path-like values;
42
+ - failure paths: dependency down, permission denied, non-zero child exit, timeouts;
43
+ - repeated and interrupted runs: run twice, kill mid-run, re-run; idempotence and partial state;
44
+ - misleading success: success text with non-zero exit, skipped tests counted as passes, swallowed errors;
45
+ - dirty state: pre-existing untracked files or stale state.
46
+ Bound every command with a timeout. A flaky result is reported with rerun counts and both run outputs, never a lucky green.
47
+ 5. **Harness hygiene.** Temporary tests, fixtures and scripts live only in `.scratchpad/` (gitignored), are never committed, and are deleted before you stop. A harness bug is fixed and rerun before calling it a product defect.
48
+ 6. **Clean up.** Remove temp files and processes; the tree is clean and HEAD unchanged. Record before and after.
49
+ 7. **Verdict.** `PASS` only when every `AC-n` in scope passed, the bug proof (if any) holds, and no high/critical adversarial finding exists. Otherwise `FAIL`.
50
+ 8. **Return the report**: `lane: verify` (or `verify-final`), `target`, `head_sha`, `verdict`, `findings` (each `id`, `severity`, `where` file:line or check, `what`, `fix`), `artifacts` = matrix summary (scenario → `AC-n` → result), commands with exit codes, bug proof runs, cleanup status.
51
+
52
+ ## Verdicts
53
+
54
+ | Verdict | When | Lead does |
55
+ |---|---|---|
56
+ | `PASS` | All of step 7 holds at the head | Moves the item on (to In Review by default) |
57
+ | `FAIL` | Any `AC-n`, check, bug proof or high/critical scenario fails | Posts findings as an item comment, moves the item → In Implementation (a Bug: → In Fixing) (In Testing → In Implementation pending F1; In Review → In Implementation allowed today) |
58
+
59
+ Medium/low adversarial findings ride along on `PASS` as notes; they do not block.
60
+
61
+ ## Stop rules
62
+
63
+ - One pass. Do not loop fix-and-retest.
64
+ - Same scenario errors three times for harness reasons: return it to the lead as a finding and stop ([No block](../workitems-process/SKILL.md#no-block)).
65
+
66
+ ## Never
67
+
68
+ - Never edit product code, tests in the branch, or the plan; never commit, push or change HEAD.
69
+ - Never move an item or post on the board.
70
+ - Never PASS an `AC-n` by reading code alone, or with skipped, quarantined or retried-until-green tests.
71
+ - Never wait unbounded or leave temp harnesses, processes or a dirty worktree behind.
@@ -15,7 +15,7 @@ The destination varies per effort, and naming it is the first act of charting
15
15
 
16
16
  ## Do Not Use When
17
17
 
18
- - The work is already small enough for one session, or is execution-shaped (slicing an already-decided plan into build tickets) rather than decision-shaped — use `to-workitems` instead.
18
+ - The work is already small enough for one session, or is execution-shaped (slicing an already-decided plan into build tickets) rather than decision-shaped — use `workitems-process` instead.
19
19
 
20
20
  ## Plan, don't do
21
21
 
@@ -0,0 +1,145 @@
1
+ ---
2
+ name: workitems-process
3
+ description: Shared reference every adl run loads first - the three dispatcher targets and their triggers, the run record, roles and write scopes, work item states, the human gates, the no-block rule, run evidence, adl MCP/CLI commands, plan and item files. Load it at the start of every session, before the target skill, and whenever a run must decide a transition or write a report.
4
+ metadata:
5
+ step: "shared"
6
+ role: "all"
7
+ states: "all"
8
+ ---
9
+
10
+ # ADL work items process (shared reference)
11
+
12
+ This skill is the package's single owner of the process rules. Every other skill, agent and prompt in the package links to a section here and does not restate it.
13
+ Tags: **[live]** = enforced today. **[pending X]** = change row `X` that is not built yet: rows F, L, P, T, H, R, S, A, V are adl-agent-control changes; rows X are adl-dispatcher changes. Never act as if a pending change is live.
14
+
15
+ Sections: [Targets and triggers](#targets-and-triggers) · [The run record](#the-run-record) · [Roles](#roles) · [States at a glance](#states-at-a-glance) · [Human gates](#human-gates) · [No block](#no-block) · [Evidence and reports](#evidence-and-reports) · [ADO and files](#ado-and-files) · [Universal preconditions](#universal-preconditions-every-run) · [Universal stop rules](#universal-stop-rules) · [Terminal handoff](#terminal-handoff).
16
+ References: [`references/workitem-states.md`](references/workitem-states.md) (states, moves, links), [`references/evidence.md`](references/evidence.md) (reports, verdicts), [`references/ado-and-git.md`](references/ado-and-git.md) (tools, plan and item files, PR wiring).
17
+
18
+ ## When to use
19
+
20
+ - At the start of every dispatched session, before the target skill's procedure.
21
+ - Whenever you must choose a transition, write a report, call ADO, or name a file.
22
+
23
+ ## Targets and triggers
24
+
25
+ | Rank | Target | Key | Skill | Lead | Done proof |
26
+ |---|---|---|---|---|---|
27
+ | 0 | `workitem-triage` | repo | `triage-workitems` | `triager` | every swept item reads back on a legal state, and each latest completed `integration` and `main` run is green or its build id is named by a Bug |
28
+ | 1 | `planning` | Feature (never a Bug) | `plan-feature` | `planner` | every in-scope item at Awaiting Approval **and** the planning PR raised; the run pauses at G1 |
29
+ | 2 | `implementation` | Feature, or one Fixes Bug (Approved through Updating Docs) keyed by the Bug **[pending L5, X2]** | `implement-feature` | `lead` | the one implementation PR merged into `integration` |
30
+
31
+ - A Feature takes two runs: one planning run, then one implementation run. A Fixes Bug takes one run: the per-Bug implementation run. One run = one worktree, one terminal, one lead session that orchestrates its sub-agents.
32
+ - **Ready:** a Feature is ready when every predecessor Feature is at Awaiting Release or Done.
33
+ - **`workitem-triage` fires on any of:** an open PBI or Bug off the ladder (`Committed` included); an item whose state may not match its evidence; a Feature roll-up is due; a Feature with no parent Epic, or (all but the first) no predecessor Feature; a red pipeline **[pending X4]**. A red pipeline is filed only when the LATEST completed run of the `integration` or `main` pipeline is red AND its build id is named in no Bug's `## Failing builds` (any state). Then: if an open Bug (New through Updating Docs) names the same failure, append the build id to it, with no comment. Otherwise file a new Bug through `report-bug`; if an earlier Bug (Done or Parked for Removal) names the same failure, that Bug is its predecessor. Older runs are never filed. A run already named never files again. Once named, a red `main` run waiting for promotion and the last red `integration` run before the fix's next run both stay quiet. Done proof: each latest completed run is green or its build id is named by a Bug.
34
+ - **`planning` fires on either:** a Feature at New whose `intent.md` is on the integration base and which is ready; or a Feature at In Progress with any child at New or In Planning (the G1 rework or requeue re-fire) **[pending X1]**. Nothing queues it. It never fires on a Bug, and never on a `Fixes to closed Features` Feature: its Bugs at New are not planned (G1 approves each Bug's Description, then X2).
35
+ - **`implementation` fires per Feature on all of:** every in-scope item (not Parked for Removal or Removed) is at Approved or later; at least one in-scope item is not Done; the Feature is ready; the Feature's planning PR is merged into `integration` **[pending X5]**. A `Fixes to closed Features` Feature never fires it under the Feature key; each of its Bugs fires alone, keyed by the Bug, at Approved through Updating Docs, until its PR merges (the X12 done proof) **[pending X2]**. A Bug at Approved starts a fresh run; a Bug at In Reproduction through Updating Docs is a died or `PR_OPEN` run, resumed from the Bug's state.
36
+ - CI is not a target; it is the last stage of implementation (ADR-019).
37
+ - **The dispatcher is a trigger:** code, no LLM. It reads the board, PRs, pipelines and branches, picks targets in rank order, and starts one session. It writes nothing to ADO. Every board write is made by the session it starts or by adl-agent-control.
38
+ - **No attempt cap.** While a key's trigger holds, the same key is re-dispatched into the same worktree and branch, and the lead resolves the cause. A session silent for 20 min is interrupted; the trigger still holds, so the key is re-dispatched.
39
+ - Live-session skills are never dispatched: `write-feature` (creates a Feature with its `intent.md`), `report-bug` (the only intake for findings, usable by any agent).
40
+
41
+ ## The run record
42
+
43
+ Rendered by `prompts/_envelope.md`. Fields: `target`, `agent`, `skill`, `key`, `key_kind` (`repo` | `Feature` | `Fixes Bug`), `feature_id`, `worktree`, `base_sha`, `head_sha`, `identity`, `run_id`. Optional: `findings`, `resume_notes`. Fields that do not apply are `null`.
44
+
45
+ - Scope is the run key. Touch nothing outside it.
46
+ - `workitem-triage`: `feature_id` is null; the whole open board is in scope.
47
+ - `identity` is always `agent-tarun`.
48
+ - Resume is not a mode. A key whose trigger still holds is re-dispatched in the same worktree and branch: read the board, the branch and any open PR, and continue. Never redo finished work.
49
+
50
+ ## Roles
51
+
52
+ | Agent | Kind | Write scope |
53
+ |---|---|---|
54
+ | `triager` | lead, `workitem-triage` | the board only: states, splits, merges, comments and predecessor links. Never writes files |
55
+ | `planner` | lead, `planning`; sub-agent in `implementation` (design update) | the Feature's plan folder, the Feature plan fields, item fields; as a sub-agent only `design.md`, `file-map-reference.md` (its `## Baseline` section and the map rows), the Feature's Baseline Sha and the LEDGER row `az<id>-design-update` |
56
+ | `lead` | lead, `implementation` | board moves. Writes no files, never reviews |
57
+ | `architect`, `critic`, `code-reviewer` | leaf | none; returns a report |
58
+ | `executor` | leaf | commits in its assigned files only (in a per-Bug run: the Bug's item file and the regression test, marked as an expected failure, first) |
59
+ | `verifier` | leaf | scratch test harness only, never committed |
60
+ | `writer` | leaf | none; returns the PR body and implementation report text |
61
+ | explore sub-agent | leaf, read-only, fast tier | none |
62
+
63
+ - **Leads never write files.** File changes are made by `executor` (code, docs, tests, the Bug item file) or by `planner` (plan files).
64
+ - **Spawning:** only the dispatched session lead (`triager`, `planner`, `lead`) spawns sub-agents; sub-agents are leaves. Any lead may spawn read-only explore sub-agents on the fast tier to read the codebase in parallel.
65
+ - **Tiers:** `frontier` = strongest reasoning, `standard` = strong coding, `fast` = cheap and quick. The tier → harness and model mapping is `[tiers]` in `adl/dispatcher.toml`; the agent → tier mapping is `tier:` in each agent file, mirrored in `[roles]`.
66
+ - Reviewer sub-agents preferably run on a different model family from `executor` when the surface allows. Not required: author and reviewer are separated by fresh sub-agent context.
67
+
68
+ ## States at a glance
69
+
70
+ PBI: `New → In Planning → Awaiting Approval → Approved → Design Validation → In Implementation / In Testing / In Review / Updating Docs → Done`, plus `Parked for Removal → Removed` and `Parked for Removal → New` (revive, human-only).
71
+
72
+ Bug: `New → Approved → In Reproduction → In Fixing ↔ In Testing ↔ In Review ↔ Updating Docs → Done`, plus `Parked for Removal → Removed` and `Parked for Removal → New` (revive, human-only). Never planned. Detail: [`references/workitem-states.md` § Bug states](references/workitem-states.md#5-bug-states).
73
+
74
+ Feature: `New → In Progress → Awaiting Release → Done`, plus `Removed`; linear, never backward, rolled up by `workitem-triage`.
75
+
76
+ - Up to Design Validation the order is strict. The four loop states are a **non-linear loop**: free moves among them, in either direction, per item. The usual order is In Testing before In Review; a default, not a rule.
77
+ - **Fence today [live]:** among the loop states only In Review → In Implementation is allowed (`workflow-rules.ts:81`). Every other loop move, and the drift loop-back In Implementation → Design Validation, are **[pending F1]**. On a refusal: post the exact refusal text as an item comment and take the path the refusal names; never work around it.
78
+ - Who moves what, Feature roll-ups and links: [`references/workitem-states.md`](references/workitem-states.md).
79
+
80
+ ## Human gates
81
+
82
+ | Gate | Decision | Who |
83
+ |---|---|---|
84
+ | **G1** | PBIs: Awaiting Approval → Approved (rework → In Planning, requeue → New), on the exact plan revision. Bugs: New → Approved, on the Bug's Description. After the planning cap the best version goes to G1 with its open findings | Tarun, on the board |
85
+ | **G2** | the promotion PR (not an item state) | Tarun |
86
+ | **G3** | Parked for Removal → Removed (revive → New) | Tarun |
87
+
88
+ Agents NEVER: move an item to Approved, Done or Removed; set Awaiting Approval by hand (`pr_create_or_update` does, pending P2); revive a parked item; approve or merge the promotion PR; auto-approve on human silence.
89
+ **No reviewer and no vote on any PR before the merge.** CI plus auto-complete merges the PR. Review is the loop's In Review state inside the run; findings go to item comments and the implementation report.
90
+
91
+ ## No block
92
+
93
+ - Nothing in a run ends blocked or waits on a person. Only G1, G2 and G3 wait on a person, and they are decided on the board. No tag and no state signals a stuck item.
94
+ - When an architect, critic, reviewer, verifier, check or tool stops progress, the **lead resolves it inside the run**: it fixes the cause through a sub-agent, re-runs a sub-agent, sends a planner sub-agent to update `design.md`, or loops the item back. A blocking finding stays valid until the re-run clears it.
95
+ - A sub-agent that cannot proceed returns its report with the obstacle as a finding (`where`, `fix`) and stops. It never decides the path itself.
96
+
97
+ | Obstacle | Path |
98
+ |---|---|
99
+ | Design drift | A planner sub-agent updates `design.md`, `file-map-reference.md` (its `## Baseline` section and the map rows) and the Feature's Baseline Sha (the new `integration` base), and adds the LEDGER row `az<id>-design-update`; Plan Hash is unchanged, since it covers `requirements.md` only. Validation runs again; nothing moves to New or In Planning |
100
+ | Code drift in the loop | In Implementation → Design Validation, re-validate, continue (pending F1) |
101
+ | Drift that would need an approved `AC-n` changed | `requirements.md` stays frozen. The lead delivers every other `AC-n`, comments the reason on that PBI and moves it to Parked for Removal (G3). If the outcome is still wanted, the next Feature plans it |
102
+ | CI red | `fix-ci`, smallest fix; expired or cancelled check → scoped `build_run` (pending H1) |
103
+ | Finding in review or verify | Back into the loop, only the listed findings |
104
+ | Bug in a closed Feature | `report-bug` |
105
+ | Tool refusal (fence or hook) | Post the refusal text as an item comment; take the path the refusal names |
106
+ | Session dies, or run ends with the PR open | The next tick resumes the same worktree and branch |
107
+ | Work already done, partly done or a duplicate | Inside a run: the sub-agent reports it as a finding with proof (a build returns `PARK`), and the lead decides. Outside a run: `workitem-triage` proposes the state, split or merge |
108
+ | Mismatch before the run starts (worktree, board state, identity) | The run does not start; the next tick re-evaluates |
109
+ | A round cap is hit (3 plan-review rounds, 3 finding rounds per item, 3 CI rounds, 2 design-update rounds) | Plan review: the best version goes to G1 with its open findings. Otherwise the lead posts the reason as an item comment and still resolves it in the run with a different approach; an item that cannot be delivered goes to Parked for Removal with proof |
110
+
111
+ ## Evidence and reports
112
+
113
+ - Every run ends with a report as its last action; format, verdicts and per-target content: [`references/evidence.md`](references/evidence.md).
114
+ - Sub-agents return a report to the lead; the lead posts it. Sub-agents post nothing and move nothing.
115
+ - **One head rule for every lane.** A lane that judges the branch (validate, verify, verify-final, review-code, review-architecture, finalize) records `head_sha` at its start and finishes against it: it reads, diffs and tests that SHA, never a later worktree state, and reports it as `head_sha`. A head that moves during the lane, or differs at start from the head the brief named, never stops or restarts the lane; the lane says so in its report. The lead compares the reported `head_sha` with the branch head and re-runs the lane at the new head when the head moved.
116
+ - Every negative result names `where` and `fix`. A negative verdict without findings is invalid.
117
+ - A run that ends without its done proof leaves the trigger holding; the next tick re-dispatches the key.
118
+
119
+ ## ADO and files
120
+
121
+ Detail: [`references/ado-and-git.md`](references/ado-and-git.md).
122
+
123
+ - ADO goes through the `adl` MCP server: `workitem_list_or_get`, `workitem_create_or_update_feature`, `workitem_create_or_update_pbi`, `workitem_create_or_update_bug`, `pr_list_or_get`, `pr_create_or_update`, `pr_review` (no role uses it before the merge), `build_list_or_get`, `build_run` (scoped to the lead's own PR, pending H1). If the server fails, use `adl mcp cli <command>`.
124
+ - Per-type mandatory fields (the agent gate enforces these per type): **Feature** — title + parentId (Epic) + description (must carry the four intent.md headings `## Why` / `## Outcome` / `## Constraints` / `## Non-goals`) + `priority` (literal set `{1, 2, 3, 4}`: 1=Very High, 2=High, 3=Medium, 4=Low); when moving off `New` (e.g. to `In Progress`), additionally `acceptanceCriteria` + `planRevision` + `planHash` + `baselineSha`; `comment` mandatory on every update. **PBI** — title + parentId (Feature) + description (must carry `## What it delivers` + `## Verification`) + `effort` (number, days, ≥0); `comment` mandatory on update. **Bug** — title + parentId (Feature) + description (must carry the five bugfix headings `## Current behaviour` / `## Expected behaviour` / `## Behaviour that must not change` / `## Responsible Feature` / `## Verification`) + `effort` (number, days, ≥0); `comment` mandatory on update. Per-type detail: [`references/ado-and-git.md` §1a](references/ado-and-git.md).
125
+ - Plans: `plans/features/az<feature id>-<slug>/{intent.md,requirements.md,design.md,file-map-reference.md,items/az<id>-<slug>.md}`. The id is allocated on the board **before** its file exists.
126
+ - Findings enter through `report-bug` only.
127
+ - Activity log: `adl activity add "<note>"` at start and finish.
128
+
129
+ ## Universal preconditions (every run)
130
+
131
+ 1. The worktree matches the run record. Mismatch: the run does not start; report expected and actual, and the next tick re-evaluates.
132
+ 2. Read the board for the key (`workitem_list_or_get --raw`). It must satisfy the target's trigger. If not, the run does not start; report the state seen. A resumed run (a died or `PR_OPEN` run, re-dispatched into the same worktree and branch) satisfies it while its done proof is unmet: a Feature's items at Approved or later with one not Done, or a Fixes Bug at Approved through Updating Docs until its PR merges. Resume from the board states, never by moving an item back.
133
+ 3. Read the key's latest comments for the earlier run's report **[comments readable: pending T1]**; do not repeat an earlier run unchanged.
134
+
135
+ ## Universal stop rules
136
+
137
+ - One run = one target and one key. Finish with its done proof or an explicit verdict; never start another target.
138
+ - Never spin: if the same command fails twice for the same reason, stop retrying it and take a different path ([No block](#no-block)).
139
+ - Never wait on a person inside a session.
140
+ - Never go silent: 20 min with no streamed output → the session is interrupted and the key re-dispatched, with your session tail as `resume_notes`. Keep producing output; a polling loop prints status.
141
+ - Never create a worktree; only adl-dispatcher does. Agents never create a branch, with one exception: in Tarun's live `write-feature` session the agent creates the intent branch from the integration base. Every other branch, and every worktree, is adl-dispatcher's to create; no agent ever recreates one.
142
+
143
+ ## Terminal handoff
144
+
145
+ End with the run report ([`references/evidence.md`](references/evidence.md)), then one line: `<target> <verdict> <key kind> <id> @ <sha>`. Never end with an offer or a question.
@@ -0,0 +1,227 @@
1
+ # ADO tools, identity, plan and item files, git
2
+
3
+ Part of [`workitems-process`](../SKILL.md). CLI facts are from the installed `adl mcp cli` usage text.
4
+ Tags: **[pending X]** = change row `X`, not built. Never act as if it is live.
5
+
6
+ ## 1. ADO tools
7
+
8
+ Use the `adl` MCP server tool. If the server is unavailable or errors for a reason other than a refusal, run the same command through `adl mcp cli <command>`. A **refusal** (wrong parent type, route not allowed, fence) is an answer, not an outage: do not retry it through the CLI.
9
+
10
+ | MCP tool | CLI fallback | Use for |
11
+ |---|---|---|
12
+ | `workitem_list_or_get` | `adl mcp cli workitem-list-or-get [--id ID] [--ids IDS] [--type TYPE] [--state STATE] [--assigned-to IDENTITY] [--limit N] [--raw]` | Read an item (state, fields, relations, tags); list by type/state |
13
+ | `workitem_create_or_update_feature` | `adl mcp cli workitem-create-or-update-feature [--id ID] --title T --parent-id ID --priority 1\|2\|3\|4 --description D [--predecessors ID[,ID…]] [--related ID[,ID…]] [--remove-predecessor ID] [--remove-related ID] [--fields JSON] [--state STATE] [--comment TEXT] [--assigned-to I] [--acceptance-criteria TEXT] [--start-date D] [--target-date D] [--plan-revision N] [--plan-hash S] [--baseline-sha S]` | Create or update a Feature; see §1a below for the per-type mandatory fields |
14
+ | `workitem_create_or_update_pbi` | `adl mcp cli workitem-create-or-update-pbi [--id ID] --title T --parent-id ID --description D --effort FLOAT [--related ID[,ID…]] [--remove-related ID] [--fields JSON] [--state STATE] [--comment TEXT] [--assigned-to I] [--acceptance-criteria TEXT] [--priority 1\|2\|3\|4] [--start-date D] [--target-date D]` | Create or update a PBI; see §1a below |
15
+ | `workitem_create_or_update_bug` | `adl mcp cli workitem-create-or-update-bug [--id ID] --title T --parent-id ID --description D --effort FLOAT [--predecessors ID] [--related ID[,ID…]] [--remove-predecessor ID] [--remove-related ID] [--fields JSON] [--state STATE] [--comment TEXT] [--assigned-to I] [--acceptance-criteria TEXT] [--priority 1\|2\|3\|4] [--start-date D] [--target-date D]` | Create or update a Bug; see §1a below |
16
+ | `pr_list_or_get` | `adl mcp cli pr-list-or-get [--id ID] [--status active\|completed\|abandoned\|all] [--repository R]` | Find the PR, read head SHA, status, merge state |
17
+ | `pr_create_or_update` | `adl mcp cli pr-create-or-update --action create\|update [--pull-request-id ID] [--title T] [--description D] [--auto-complete\|--no-auto-complete] [--merge-strategy Squash] [--delete-source-branch] [--repository R]` | Open or update a PR; also does the PR wiring (§6) **[pending P1/P2/P4]** |
18
+ | `pr_review` | `adl mcp cli pr-review …` | **Not used.** No reviewer and no vote on any PR before the merge to `integration` |
19
+ | `build_list_or_get` | `adl mcp cli build-list-or-get [--build-id ID] [--branch B] [--top N] [--tail N]` | Pipeline runs and logs |
20
+ | `build_run` | `adl mcp cli build-run --id ID [--branch B]` | Re-queue only the lead's own PR validation on its source branch **[pending H1]**; denied today |
21
+
22
+ Tools not built yet (never act as if live):
23
+
24
+ | Need | Row | Until built |
25
+ |---|---|---|
26
+ | Read a work item's comments | T1 | Not readable by tool (`--raw` shows only the latest History value). A run that cannot read earlier reports works from board states, `git log` and the PR, and re-runs evidence whose head is stale |
27
+ | Attachments on a Feature (read, upload, delete) | T2 | `pr_create_or_update` attaches the mandatory ones itself once P4 ships |
28
+ | Named Feature plan fields | T3 | Pass `Custom.PlanRevision`, `Custom.PlanHash`, `Custom.BaselineSha` through `--fields` (reference names and agent writability not yet confirmed through the API); a refusal: post the exact error as an item comment and take the path it names |
29
+ | Activity log | A1 | `adl activity add "<note>"` / `adl activity list` write and read `.adl/agent-activity.sqlite` (local, gitignored) |
30
+
31
+ Patterns:
32
+ - Move state: `workitem_create_or_update_<type> --id <id> --state "<State Name>"` (the right one per type: `-feature`, `-pbi`, `-bug`). Use the exact ADO state name.
33
+ - Post a comment: `workitem_create_or_update_<type> --id <id> --comment "<text>"`. Comments are mandatory on every update.
34
+ - Supplying `--parent-id` on an update **moves** the item to that parent; the old parent link is removed.
35
+ - The installed CLI accepts only `--merge-strategy Squash`.
36
+
37
+ ### 1a. Per-type mandatory fields (the canonical reference)
38
+
39
+ Use the type-named tool. The agent gate enforces the rules below — calls that violate them are refused, not silently dropped.
40
+
41
+ **Feature** — `workitem_create_or_update_feature` / `adl mcp cli workitem-create-or-update-feature`
42
+ - Required on create, and on any update while the Feature is at `New`: `title` (non-empty); `parentId` (must be an Epic); `description` (non-empty AND must carry the four intent.md headings `## Why`, `## Outcome`, `## Constraints`, `## Non-goals`); `priority` (literal set `{1, 2, 3, 4}`: 1=Very High, 2=High, 3=Medium, 4=Low — not any integer). `comment` non-empty on every update.
43
+ - Past `New`, an update carries the `comment` (and whatever it actually changes) — the create fields are not re-sent.
44
+ - State-conditional: when the existing state is `New` and the call moves to `In Progress`, additionally `acceptanceCriteria` (non-empty), `planRevision` (positive integer), `planHash` (non-empty string), `baselineSha` (non-empty string). Without those, the move is refused.
45
+ - Create state is always `New`. Cannot create at any other state.
46
+ - Predecessors: ≥1 unless the project has no non-Fixes Feature yet (L2 soft warning kept).
47
+
48
+ **PBI (`Product Backlog Item`)** — `workitem_create_or_update_pbi` / `adl mcp cli workitem-create-or-update-pbi`
49
+ - Required on create: `title` (non-empty); `parentId` (must be a Feature); `description` (non-empty AND must carry `## What it delivers` + `## Verification` headings); `effort` (number, ≥0, days; float accepted).
50
+ - On update: `comment` non-empty — and nothing else. The create fields are not re-sent.
51
+ - Predecessors are forbidden (L3 — soft, via a `warnings` field rather than a hard refusal).
52
+ - Plan fields (`plan-revision`, `plan-hash`, `baseline-sha`) are forbidden (T3 — hard).
53
+
54
+ **Bug** — `workitem_create_or_update_bug` / `adl mcp cli workitem-create-or-update-bug`
55
+ - Required on create: `title` (non-empty); `parentId` (must be a Feature, typically a Fixes Feature); `description` (non-empty AND must carry the five bugfix headings `## Current behaviour`, `## Expected behaviour`, `## Behaviour that must not change`, `## Responsible Feature`, `## Verification`); `effort` (number, ≥0, days; float accepted).
56
+ - On update: `comment` non-empty — and nothing else. The create fields are not re-sent.
57
+ - Predecessors: at most one, only when the parent is the `Fixes to closed Features` Feature (L4); for the first Bug in a Fixes Feature, none.
58
+ - `related` is required when the parent is the Fixes Feature (the related link points to the Responsible Feature) (L4).
59
+ - Plan fields are forbidden (T3 — hard).
60
+
61
+ **Cross-cutting**
62
+ - `priority` is the literal set `{1, 2, 3, 4}`. Named: 1=Very High, 2=High, 3=Medium, 4=Low. Stored as `Microsoft.VSTS.Common.Priority` (int). Surfaces on the read shape as `priority: number | null`.
63
+ - `effort` is in days, accepts floats. Stored as `Microsoft.VSTS.Scheduling.Effort` (number, ≥0). Surfaces on the read shape as `effort: number | null`.
64
+ - `comment` is mandatory on every update (tarun: "comments field is also mandatory"). Even no-op-shaped updates must carry a comment. On create, `comment` is optional.
65
+ - `AC` is required on Feature only (state-conditional, see above). PBI/Bug read also embeds it; they just don't require it at create.
66
+ - The tool name IS the type. Passing an id of another type (a PBI id to `workitem_create_or_update_feature`, say) is refused by name — there is no blanket write tool to fall back on.
67
+
68
+ ## 2. Identity
69
+
70
+ - Every session runs as `agent-tarun`; `ADL_AGENT_ID_AGENT` is set when the session starts and selects the identity for every ADO and git network call. `agent-reviewer` exists only for the `integration → main` promotion (G2); no run uses it.
71
+ - Check it with `adl id whoami`. Never override the identity the session was started with.
72
+ - Never read vault files. Never pass a token on a command line or in a file. Never set `ADL_HUMAN_AZDO`.
73
+ - Plain `git` handles Azure DevOps credentials through the managed front controller; never configure credentials yourself.
74
+
75
+ ## 3. Hierarchy
76
+
77
+ - **Epic > Feature > PBI/Bug.** A PBI or Bug parents to a Feature; a Feature parents to an Epic. The server refuses a wrong-typed parent by name. A Bug never parents directly to an Epic.
78
+ - A work item has exactly one parent. Ordering is never expressed by parenting.
79
+ - Predecessors, Related links and readiness: [`workitem-states.md` § Links](workitem-states.md#4-links).
80
+ - Agents never create Epics or Features in a run (a Feature is created in the live `write-feature` session). `epic:` and `feature:` are authored values; a missing Feature is never a create: report it with the id you looked for.
81
+ - Tracked types: Feature, Product Backlog Item, Bug. No Tasks.
82
+
83
+ ## 4. Plan files
84
+
85
+ One folder per Feature: `plans/features/az<feature id>-<slug>/` holding `intent.md`, `requirements.md`, `design.md`, `file-map-reference.md` and `items/az<id>-<slug>.md`. Git holds the plan; the board holds state, links, plan fields, attachments and comments.
86
+
87
+ - **The id is the identity.** Allocate the item on the board first, then create its file. No placeholder files, no renames. An item not yet allocated is a row in `requirements.md`'s `## Items` table with an empty id cell.
88
+ - **Nothing moves between directories.** State lives on the board, never in a folder or filename.
89
+ - Frontmatter `status` mirrors the board state; the board is authoritative. Plan Revision, Plan Hash and Baseline Sha are never frontmatter.
90
+ - The file contracts (frontmatter + sections) are the tables below; there is no per-repo `plans/templates/`.
91
+
92
+ **`intent.md`** (Tarun, live `write-feature` session; agents never edit it). Frontmatter: `type: intent`, `title`, `status`, `work_item` (the Feature's board URL), `last_update`, optional `sources`.
93
+
94
+ | Section | Rule |
95
+ |---|---|
96
+ | `## Why` | required |
97
+ | `## Outcome` | required; what is true when it's done |
98
+ | `## Constraints` | required |
99
+ | `## Non-goals` | required |
100
+ | `## Open questions` | optional |
101
+
102
+ **`requirements.md`** (the what and why; frozen at G1 under the plan hash). Frontmatter: `type: feature`, `title`, `status`, `epic` (the Epic's board URL), `work_item` (the Feature's board URL), `last_update`, `sources` (lists `intent.md` first).
103
+
104
+ | Section | Rule |
105
+ |---|---|
106
+ | `## Problem` | required; holds the user stories |
107
+ | `## Acceptance criteria` | required; numbered `AC-1…`, each one EARS sentence, each checkable by a test |
108
+ | `## Scope` | required; In and Non-goals |
109
+ | `## Predecessors` | the Feature's predecessor Features, mirrored as board links |
110
+ | `## Items` | `Id \| Title \| Type \| Delivers \| Verification` (by AC ids); no Predecessor column |
111
+ | `## Open questions for G1` | required; may say "none" |
112
+ | `## Revision log` | required, append-only: `Rev \| Date \| Baseline \| Trigger \| Changes` |
113
+
114
+ **`design.md`** (the how; outside the plan hash; a planner sub-agent may update it in the implementation run). Frontmatter: `type: design`, `title`, `status`, `work_item`, `last_update`, and `sources` listing `requirements.md`.
115
+
116
+ | Section | Rule |
117
+ |---|---|
118
+ | `## Solution` | required; the approach per item, with `file:line` read at the Baseline Sha |
119
+ | `## Decisions` | required; includes the RALPLAN-DR summary: principles, decision drivers, ≥ 2 options; deliberate mode for high-risk work |
120
+ | `## Verification` | required; every `AC-n` → its test, tests first |
121
+ | `## Docs impact` | required; each doc path or section the change updates, with its item, or "No docs impact" |
122
+ | `## Size estimate` | required; items, touchpoints and changed lines, with the working shown, against the sizing gate |
123
+ | `## Risks` | required; each with a concrete mitigation |
124
+
125
+ **`file-map-reference.md`**. Frontmatter: `type: file-map`, `title`, `status`, `work_item`, `last_update`. Sections: `## Baseline` (the `integration` SHA; equals the Feature's Baseline Sha) and `## Map` (`Path | Kind (read / change / new) | Why | Items`).
126
+
127
+ **Touchpoint.** A touchpoint is a `## Map` row of Kind `change` or `new`. A `read` row is not a touchpoint. The sizing gate counts touchpoints.
128
+
129
+ - **EARS:** every acceptance criterion is one sentence "THE SYSTEM SHALL …", optionally opened by WHEN, WHILE, IF … THEN or WHERE. Each becomes one test, written first **[check pending R4]**.
130
+ - **Sizing gate:** ≤ 6 items, ≤ ~40 touchpoints, ≤ ~1,500 changed lines, no shims, one coherent outcome. Over it: split or cut.
131
+
132
+ **Feature plan fields** (on the board, written by the planner):
133
+
134
+ | Field | Rule |
135
+ |---|---|
136
+ | Plan Revision | increments once per G1 submission; the review rounds inside one planning run share it |
137
+ | Plan Hash | sha256 of `requirements.md` only. Readers recompute `shasum -a 256 requirements.md` and compare; on a mismatch, name both hashes in a Feature comment and stop the step that needed it. The check at the Design Validation move is **[pending F7]** |
138
+ | Baseline Sha | the `integration` commit the plan was written against; a design update in the implementation run sets it to the new base |
139
+
140
+ **Attachments** (on the Feature only, both mandatory, attached by `pr_create_or_update` **[pending P4, needs T2]**): `plan-r<N>-<sha7>.md` with the planning PR (`requirements.md`, `design.md`, `file-map-reference.md` and every item file, in one file; `<N>` = Plan Revision, `<sha7>` = first 7 of Plan Hash); `impl-report-pr<id>.md` with the implementation PR (per item: what changed, tests run, review findings and their resolution, docs touched; design updates). A Fixes Bug's report attaches to its Fixes Feature. The implementation run adds no `plan-r*`. PBIs and Bugs carry no attachments. An attachment is never edited or replaced. The one delete allowed is of a mistaken upload, in the run that made it; it is refused for a `plan-r*` file once an item of that Feature has left Awaiting Approval (pending T2). On API 7.1, delete means removing the `AttachedFile` relation; the stored file stays.
141
+
142
+ **LEDGER.** Every agent commit that touches `plans/` adds one `plans/LEDGER.md` row, written by whoever commits. Table `Date | Id | Area | Event | Refs`, newest first; Event ≤ 99 characters.
143
+
144
+ | Event | Row id | Written by |
145
+ |---|---|---|
146
+ | Intent | `az<id>-intent` | the agent in Tarun's live `write-feature` session |
147
+ | Plan revision | `az<id>-plan-r<N>` | the planner, planning run |
148
+ | Design update | `az<id>-design-update` | the planner sub-agent, implementation run |
149
+ | Fixes Bug item file | `az<id>-bug` | the executor, per-Bug run |
150
+
151
+ ## 5. Item files
152
+
153
+ One file per PBI or Bug, `items/az<id>-<slug>.md` in its Feature's folder. The item file text **is** the work item's fields: keep the ADO Description and Acceptance Criteria in sync with it.
154
+
155
+ Frontmatter (both types):
156
+
157
+ ```yaml
158
+ ---
159
+ type: pbi # pbi | bug
160
+ title: Parse the dispatcher config
161
+ status: Awaiting Approval # board state
162
+ work_item: https://dev.azure.com/<org>/<project>/_workitems/edit/<item id>
163
+ feature: https://dev.azure.com/<org>/<project>/_workitems/edit/<Feature id> # the Feature's full board URL
164
+ last_update: 2026-10-10T12:00:00Z
165
+ ---
166
+ ```
167
+
168
+ **PBI** (written by the planner in the planning run; a PBI that triage creates (a split) is at New, so it goes through planning: the planner writes its item file in the Feature's next planning run, which the requeue re-fire triggers). Sections: `## What it delivers`, `## Verification` (each line names its `AC-n`), optional `## Related`. No `## Predecessors`.
169
+
170
+ **Fixes Bug.** `report-bug` creates the Bug on the board only, at New, under the Epic's `Fixes to closed Features` Feature. Its **Description** holds the bugfix shape:
171
+
172
+ | Section | Holds |
173
+ |---|---|
174
+ | `## Current behaviour` | what happens now, with the repro and its output; for a red pipeline it cites the first failing build id once |
175
+ | `## Expected behaviour` | one EARS sentence per criterion |
176
+ | `## Behaviour that must not change` | what the fix must leave alone |
177
+ | `## Responsible Feature` | required; the closed Feature that should have got it right, or for a red pipeline the merged Feature (for a `fix/` PR, the merged Bug's Responsible Feature) |
178
+ | `## Verification` | a regression test that fails before the fix |
179
+
180
+ G1 approves that Description. In the per-Bug run the **executor** commits the item file as the first commit on `fix/az<bug id>-<slug>`: frontmatter with `type: bug` and `feature:` = the Fixes Feature, the five sections above, plus `## Predecessors` mirroring the board predecessor link (L4: the predecessor Bug in that Fixes Feature, or `none` for the first), and the LEDGER row `az<id>-bug`. Location: `plans/features/az<fixes id>-fixes-to-closed-features/items/az<id>-<slug>.md`; the first Bug of a Fixes Feature creates the folder. The Fixes Feature is never planned and never rolled up; the item file is the Bug's whole plan.
181
+
182
+ ## 6. PR wiring
183
+
184
+ `pr_create_or_update` does all PR-to-board wiring **[pending P1, P2, P4]**. One rule decides the kind, from the source branch and the board:
185
+
186
+ - A source branch `docs/az<id>-<slug>-plan` (the `-plan` suffix) means a **planning PR**. It wires the Feature's in-scope items at In Planning.
187
+ - Any other `<type>/az<id>-<slug>` branch means an **implementation PR**. It wires the in-scope items at Approved or later: the Feature's items, or, for a Bug branch `fix/az<bug id>-<slug>`, that one Bug.
188
+ - Items at Parked for Removal or Removed are never wired.
189
+ - A PR with no item in a wireable state is **ordinary**: no work-item links, no state moves, no attachment, no impl-report. So the `intent.md` PR from `docs/az<id>-<slug>` stays ordinary even when PBIs already exist at New, because none is at Approved or later.
190
+
191
+ Agents pass nothing, add no item links or `AB#` references to PRs by hand, and make none of these moves.
192
+
193
+ | PR | Source branch | Linked items | `transitionWorkItems` | Raised → | Merged → | Attachment |
194
+ |---|---|---|---|---|---|---|
195
+ | Planning | `docs/az<id>-<slug>-plan` | the Feature's in-scope items at In Planning | false | items → Awaiting Approval | nothing | `plan-r<N>-<sha7>.md`, on the Feature |
196
+ | Implementation (Feature) | `<type>/az<id>-<slug>`, the id a Feature | the Feature's in-scope items at Approved or later | true | items → Updating Docs | items → Done | `impl-report-pr<id>.md`, on the Feature |
197
+ | Implementation (Fixes Bug) | `fix/az<bug id>-<slug>` | that Bug, at Approved or later | true | Bug → Updating Docs | Bug → Done | `impl-report-pr<id>.md`, on the Fixes Feature |
198
+ | Ordinary | any branch with no item in a wireable state (e.g. the `intent.md` PR on `docs/az<id>-<slug>`, even with PBIs at New), or a branch that names no work item | none | false | nothing | nothing | none; no impl-report |
199
+
200
+ - A planning PR's merge never moves items to Done; only the implementation PR's merge does (verify V2 on a real PR).
201
+ - Today `pr_create_or_update` links no items and moves nothing.
202
+
203
+ ## 7. Git
204
+
205
+ | Branch | Name | Rules |
206
+ |---|---|---|
207
+ | Planning | `docs/az<feature id>-<slug>-plan` | Created by adl-dispatcher, pushed once. Holds the plan folder edits; docs-only planning PR to `integration`. Re-entry reuses the existing branch: bring it current with `git merge --no-edit origin/integration`. Never rebase, never force-push, never recreate it |
208
+ | Implementation | `feat/az<feature id>-<slug>` (or the fitting type) | Created by adl-dispatcher, pushed once. One branch, one PR per Feature; every item's commits go on it. Never force-push; every implementation run starts by merging `origin/integration` into it (`git merge origin/integration`), before Design Validation |
209
+ | Fixes Bug | `fix/az<bug id>-<slug>` | Created by adl-dispatcher, pushed once. One branch and one PR per Approved Fixes Bug; same rules as implementation |
210
+ | `intent.md` | `docs/az<feature id>-<slug>` | Created by the agent in Tarun's live `write-feature` session, from `origin/integration`. Ordinary docs PR; no wiring |
211
+ | Triage worktree | `workitem-triage` | Repo-wide run; pushes no branch, raises no PR |
212
+
213
+ - Branch names follow the global `<type>/<kebab>` rule. Only adl-dispatcher creates worktrees, at most 3 checkouts per repo; agents never `git worktree add`. Agents never create a branch, with one exception: in Tarun's live `write-feature` session the agent creates the intent branch `docs/az<id>-<slug>` from `origin/integration`. Every other branch, and every worktree, is adl-dispatcher's to create; no agent ever recreates one.
214
+ - Commits: `<type>(<scope>): <lowercase subject>`, type ∈ `feat|fix|docs|refactor|perf|chore`. No `!`. Never `release:`. Each commit independently green, one topic. Never `git stash`.
215
+ - **`AB#<id>` goes in the commit body**, never the subject, on implementation and Fixes Bug commits only (the item's id). Planning commits carry none: a hand-written reference would let ADO move items when a planning PR completes.
216
+ - PR title follows the commit grammar, at most 80 characters. PR body, five sections (the first three enforced today, all five pending P3):
217
+
218
+ | Section | Content |
219
+ |---|---|
220
+ | `## Summary` | what the PR does |
221
+ | `## Why` | the reason |
222
+ | `## Changes` | the changes |
223
+ | `## Test plan` | one line per EARS criterion → its test; a planning PR writes "none (docs-only)" |
224
+ | `## Security impact considered` | the ISMS consideration; a planning PR writes "none (docs-only)" |
225
+
226
+ An `## Evidence` section is optional; the full record is the `impl-report-pr<id>.md` attachment.
227
+ - Every PR targets `integration`. CI plus auto-complete (squash, source branch deleted) merges it. The `integration → main` promotion PR is opened by the pipeline and approved only by Tarun (G2).