forgedock 1.22.0 → 1.23.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Legacy full orchestrator (triage, investigation wave, synthesis, DAG) — reached via /orchestrate --path full
|
|
3
|
+
argument-hint: "[milestone <slug> | #1 #2 #3 | next <N> | fast-lane | priority:P0] [--auto|--confirm]"
|
|
4
|
+
user-invocable: false
|
|
5
|
+
install: internal
|
|
6
|
+
---
|
|
7
|
+
<!-- SPDX-FileCopyrightText: Copyright (c) RapierCraft Studios -->
|
|
8
|
+
<!-- SPDX-License-Identifier: AGPL-3.0-or-later -->
|
|
9
|
+
|
|
10
|
+
# /orchestrate — Multi-Issue Parallel Orchestrator
|
|
11
|
+
|
|
12
|
+
**Input**: $ARGUMENTS
|
|
13
|
+
|
|
14
|
+
`--auto` and `--confirm` authorize the dispatch checkpoint; they are control
|
|
15
|
+
flags, not part of the issue-set query. `--deep-plan` requests the full analysis
|
|
16
|
+
path, and `--max-concurrent N` only tunes the dispatch cap.
|
|
17
|
+
|
|
18
|
+
This file is the slim dispatcher. Detailed phase content lives in `commands/orchestrate/`.
|
|
19
|
+
|
|
20
|
+
## OpenCode Preflight
|
|
21
|
+
|
|
22
|
+
When `FORGE_RUNTIME=opencode` (or an OpenCode runtime marker is present), run the
|
|
23
|
+
deterministic preflight at `$FORGE_HOME/bin/orchestrate-preflight.mjs` immediately,
|
|
24
|
+
before reading `orchestrate/config.md`, this workflow, or any phase spec. The helper
|
|
25
|
+
resolves the repository from `forge.yaml`, including a parent config when the target
|
|
26
|
+
is a nested Git worktree:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
node "$FORGE_HOME/bin/orchestrate-preflight.mjs" \
|
|
30
|
+
--repo "$GH_REPO" \
|
|
31
|
+
--args "$ARGUMENTS"
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
The preflight is a compact mechanical adapter for issue resolution, eligibility,
|
|
35
|
+
explicit dependencies, scoped issue-body file overlap, database serialization, and
|
|
36
|
+
the initial ready queue. If it returns a supported plan with `requiresDeepPlan: false`
|
|
37
|
+
and `confirmed: true`, launch `dispatchNow` with native background `task` calls
|
|
38
|
+
immediately. Without an explicit `--auto` or `--confirm` argument, present the
|
|
39
|
+
compact plan and ask for one confirmation; after the user confirms, launch the
|
|
40
|
+
plan's ready queue without re-reading the large phase files. Do not load the full
|
|
41
|
+
Phase 3 or Phase 4 prose just to ask that question.
|
|
42
|
+
|
|
43
|
+
Continue through the phase files when the plan says `requiresDeepPlan`, the input is
|
|
44
|
+
unsupported, preflight fails, or a task-result event requires recovery. This adapter
|
|
45
|
+
never closes, deduplicates, or edits issues; the full shared workflow remains the
|
|
46
|
+
authority for investigations, review-finding cascade handling, recovery, cleanup,
|
|
47
|
+
and reporting.
|
|
48
|
+
|
|
49
|
+
For a supported compact OpenCode plan, stop after the fast-path dispatch. The phase
|
|
50
|
+
execution order below is the fallback path for deep plans, unsupported inputs,
|
|
51
|
+
preflight failures, and task-result recovery; do not read it merely to confirm or
|
|
52
|
+
dispatch a compact plan.
|
|
53
|
+
|
|
54
|
+
## Execution Order
|
|
55
|
+
|
|
56
|
+
Read and execute phases in sequence. Each phase file is self-contained. Resolve every path from the spec root defined in the Quick Reference below.
|
|
57
|
+
|
|
58
|
+
| Step | File | Description |
|
|
59
|
+
|------|------|-------------|
|
|
60
|
+
| 0 | `orchestrate/config.md` | Hard rules, config resolution, multi-repo support — READ FIRST |
|
|
61
|
+
| 1 | `orchestrate/phase-1-resolve.md` | Resolve the issue set from input |
|
|
62
|
+
| 2 | `orchestrate/phase-2-triage.md` | Investigation-first triage, Wave 0 |
|
|
63
|
+
| 2.5 | `orchestrate/phase-2.5-synthesis.md` | Investigation synthesis and deconfliction |
|
|
64
|
+
| 3 | `orchestrate/phase-3-dependency.md` | Dependency analysis, DAG construction, execution plan |
|
|
65
|
+
| 4 | `orchestrate/phase-4-execution.md` | Streaming DAG execution, agent dispatch, stall detection |
|
|
66
|
+
| 5 | `orchestrate/phase-5-cleanup.md` | Post-batch cleanup sweep and agent audit |
|
|
67
|
+
| 6 | `orchestrate/phase-6-report.md` | Consolidated report and pipeline summary |
|
|
68
|
+
| — | `orchestrate/safety.md` | Safety rules and examples (reference) |
|
|
69
|
+
|
|
70
|
+
## Quick Reference
|
|
71
|
+
|
|
72
|
+
**Spec root (MANDATORY)**: read every file below from `${CLAUDE_PLUGIN_ROOT}` — the install root of the ForgeDock plugin that is running this command (Claude Code fills it in when it loads the spec). Only if that path does not start with `/` (not a Claude Code plugin session: install.sh, Codex, OpenCode) use `$FORGE_HOME` instead. Never read sub-files from `$FORGE_HOME` when the plugin root resolved: an exported `FORGE_HOME` can point at a different, older ForgeDock checkout, and mixing roots runs stale phase specs.
|
|
73
|
+
|
|
74
|
+
**Raw reads are not substituted (MANDATORY)**: Claude Code fills in the plugin root only in the spec it loads (this file), never in files you open with Read. The phase files contain the placeholder written as `$` immediately followed by `{CLAUDE_PLUGIN_ROOT}`. Before running any bash block taken from a phase file, replace every occurrence of that placeholder with `${CLAUDE_PLUGIN_ROOT}` (the resolved root shown here), exactly as Claude Code would have. Left unreplaced it is rejected as a non-absolute path and resolution falls back to `$FORGE_HOME`, which may be stale.
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/config.md # ALWAYS READ FIRST
|
|
78
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-1-resolve.md
|
|
79
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-2-triage.md
|
|
80
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-2.5-synthesis.md
|
|
81
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-3-dependency.md
|
|
82
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-4-execution.md
|
|
83
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-5-cleanup.md
|
|
84
|
+
Read: ${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/phase-6-report.md
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
The orchestrator reads only the phase file(s) relevant to the current step rather than
|
|
88
|
+
loading the full 2300-line monolith upfront.
|
package/commands/orchestrate.md
CHANGED
|
@@ -1,86 +1,82 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Orchestrate parallel
|
|
3
|
-
argument-hint: "
|
|
2
|
+
description: Orchestrate several issues in parallel — launches one lean work-on lane per issue (background shell or agent), GitHub is the register
|
|
3
|
+
argument-hint: "<#1 #2 #3 | milestone <slug> | label <name>> [--parallel K] [--lane L] [--path full]"
|
|
4
4
|
---
|
|
5
5
|
<!-- SPDX-FileCopyrightText: Copyright (c) RapierCraft Studios -->
|
|
6
6
|
<!-- SPDX-License-Identifier: AGPL-3.0-or-later -->
|
|
7
7
|
|
|
8
|
-
# /orchestrate —
|
|
8
|
+
# /orchestrate — parallel lean work-on lanes
|
|
9
9
|
|
|
10
10
|
**Input**: $ARGUMENTS
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
and
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
The orchestrator reads only the phase file(s) relevant to the current step rather than
|
|
86
|
-
loading the full 2300-line monolith upfront.
|
|
12
|
+
You are the orchestrator. Resolve the issues, order them, and run each one in its own lane. Each lane
|
|
13
|
+
runs the lean work-on (validate → plan → implement → fix/regression review → PR → merge), which records
|
|
14
|
+
every step on the issue. You triage and order the set yourself (no sub-agent investigations), but never implement an
|
|
15
|
+
issue yourself.
|
|
16
|
+
|
|
17
|
+
## 1. Legacy path
|
|
18
|
+
|
|
19
|
+
If the input contains `--path full`, stop: read `${CLAUDE_PLUGIN_ROOT}/commands/orchestrate/legacy.md`
|
|
20
|
+
and follow it instead (the previous multi-phase orchestrator).
|
|
21
|
+
|
|
22
|
+
## 2. Resolve, triage and build the DAG
|
|
23
|
+
|
|
24
|
+
Do this yourself from issue text and the code. Spawn no sub-agents here.
|
|
25
|
+
|
|
26
|
+
1. **Resolve.**
|
|
27
|
+
- Explicit numbers (`#12 13 14`) are used as given.
|
|
28
|
+
- `milestone <slug>` uses `gh issue list --milestone "<slug>" --state open --json number --jq '.[].number'`.
|
|
29
|
+
- `label <name>` uses the same with `--label`.
|
|
30
|
+
|
|
31
|
+
Keep only plain integers and drop closed issues.
|
|
32
|
+
2. **Triage.** For each issue, read it once (`gh issue view N --json title,body,labels`) and record:
|
|
33
|
+
- **Ready / skip.** Skip when it is labelled `needs-human` or `workflow:merged`, or an open PR already
|
|
34
|
+
closes it (`gh pr list --search "Closes #N" --state open`). Say why.
|
|
35
|
+
- **Files.** The files or areas it will likely touch: paths named in the issue, or a quick
|
|
36
|
+
`git grep` of the symbols it names. Keep this to a few greps per issue, not an investigation.
|
|
37
|
+
- **Size.** S, M or L, from the scope the issue describes.
|
|
38
|
+
3. **Build the DAG.** Edge X → N means N waits until X merges:
|
|
39
|
+
- **Explicit:** `Depends on #X` / `Blocked by #X` where X is in the set. An open X outside the set
|
|
40
|
+
means N is skipped as blocked.
|
|
41
|
+
- **Conflict:** two issues that will edit the same file or the same function run one after the
|
|
42
|
+
other (smaller first), so their PRs don't conflict. Different files run in parallel.
|
|
43
|
+
- **Logical:** one issue's fix is needed by another (for example, it adds the helper the other uses).
|
|
44
|
+
|
|
45
|
+
If you find a cycle, break it at the weakest (conflict) edge and say so.
|
|
46
|
+
4. **Show the plan** as one table: issue, title, size, likely files, waits-on, wave. Then proceed
|
|
47
|
+
without asking.
|
|
48
|
+
|
|
49
|
+
`K` = `--parallel` (default 3). `L` = `--lane` if given, otherwise the repo's base lane from forge.yaml.
|
|
50
|
+
|
|
51
|
+
## 3. Launch lanes
|
|
52
|
+
|
|
53
|
+
Keep at most K lanes running. Start issues in DAG order: every issue whose waits-on have all merged.
|
|
54
|
+
|
|
55
|
+
- **Shell lane (default, when `forgedock` is on PATH).** One `Bash` call per issue with
|
|
56
|
+
`run_in_background: true`:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
forgedock run-issue <N> --lane <L>
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
The harness notifies you when the lane exits. Its last line is `issue #N → <outcome>`.
|
|
63
|
+
- **Agent lane (only when the `forgedock` CLI is unavailable).** Spawn one background agent per issue.
|
|
64
|
+
The prompt is:
|
|
65
|
+
|
|
66
|
+
> Resolve issue #N (gh issue view N --comments). If already fixed or invalid, comment the file:line
|
|
67
|
+
> evidence and stop. Otherwise fix it with a regression test, run the relevant tests, commit on a
|
|
68
|
+
> branch, push, open a PR with Closes #N, and comment a summary (root cause, changes, tests, PR) on
|
|
69
|
+
> the issue.
|
|
70
|
+
|
|
71
|
+
The agent does not merge.
|
|
72
|
+
|
|
73
|
+
When a lane finishes:
|
|
74
|
+
- `merged` or `invalid`: start the next ready issue.
|
|
75
|
+
- `needs-human`: read the issue's last comment for the reason, and mark its dependents skipped.
|
|
76
|
+
- `engine-error`: relaunch it once.
|
|
77
|
+
- `ci-pending` or `deferred`: leave it. A later `/orchestrate` resumes it.
|
|
78
|
+
|
|
79
|
+
## 4. Report
|
|
80
|
+
|
|
81
|
+
When all lanes have finished, print one table: issue, outcome, PR, minutes. Then list each
|
|
82
|
+
`needs-human` or skipped issue with its one-line reason. Nothing else.
|
|
@@ -155,20 +155,17 @@ Deterministically verifies a staging→main bundle's acceptance criteria against
|
|
|
155
155
|
|
|
156
156
|
### `/orchestrate`
|
|
157
157
|
|
|
158
|
-
**Parallel
|
|
158
|
+
**Parallel lean work-on lanes.**
|
|
159
159
|
|
|
160
|
-
|
|
160
|
+
Resolves the issues, triages them and builds a dependency DAG (explicit `Depends on`, same-file conflicts, logical order), then launches one lane per issue (`forgedock run-issue N` as a background shell, or an agent when the CLI is unavailable), at most K at a time. Each lane runs the lean work-on and records every step on its issue.
|
|
161
161
|
|
|
162
162
|
```bash
|
|
163
|
-
/orchestrate milestone launch-campaign # All issues in a milestone
|
|
164
163
|
/orchestrate #42 #43 #44 # Specific issues
|
|
165
|
-
/orchestrate
|
|
166
|
-
/orchestrate
|
|
167
|
-
/orchestrate
|
|
164
|
+
/orchestrate milestone launch-campaign # All open issues in a milestone
|
|
165
|
+
/orchestrate label bug --parallel 4 # All open issues with a label, 4 lanes
|
|
166
|
+
/orchestrate #42 #43 --path full # Legacy multi-phase orchestrator
|
|
168
167
|
```
|
|
169
168
|
|
|
170
|
-
Each sub-agent gets its own git worktree and GitHub issue thread. No interference between parallel agents.
|
|
171
|
-
|
|
172
169
|
---
|
|
173
170
|
|
|
174
171
|
#### `/milestone`
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "forgedock",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.23.0",
|
|
4
4
|
"description": "Autonomous development pipeline for coding agents. GitHub as institutional memory, with native Claude Code and OpenCode entrypoints.",
|
|
5
5
|
"bin": {
|
|
6
6
|
"forgedock": "bin/forgedock.mjs"
|