@detergent-software/conductor 3.2.0-dev.11 → 3.2.0-dev.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +6 -0
- package/package.json +3 -3
- package/plugin/skills/work-item/SKILL.md +10 -8
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
Releases are tagged `conductor-v<version>` and staged on npm by `atk-conductor-release` (`pipelines/release-conductor.yml`), which writes each section below. `scripts/check-changelog.mjs` fails when a tag has no section here.
|
|
4
4
|
|
|
5
|
+
## [3.2.0-dev.12](https://emergentcode.visualstudio.com/Emergent%20Software/_git/Emergent.AgenticToolkit/branchCompare?baseVersion=GTconductor-v3.2.0-dev.11&targetVersion=GTconductor-v3.2.0-dev.12) (2026-10-22)
|
|
6
|
+
|
|
7
|
+
### Documentation
|
|
8
|
+
|
|
9
|
+
* **conductor:** name another Azure DevOps repo in work-item (ATK-722) ([20e2c45](https://emergentcode.visualstudio.com/Emergent%20Software/_git/Emergent.AgenticToolkit/commit/20e2c454ae77b9e83f8589a619a1a68aac956693))
|
|
10
|
+
|
|
5
11
|
## [3.2.0-dev.11](https://emergentcode.visualstudio.com/Emergent%20Software/_git/Emergent.AgenticToolkit/branchCompare?baseVersion=GTconductor-v3.2.0-dev.10&targetVersion=GTconductor-v3.2.0-dev.11) (2026-10-22)
|
|
6
12
|
|
|
7
13
|
### Bug Fixes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@detergent-software/conductor",
|
|
3
|
-
"version": "3.2.0-dev.
|
|
3
|
+
"version": "3.2.0-dev.12",
|
|
4
4
|
"description": "Conductor: the local daemon that runs conducted projects' work loops (conduct serve) and its conduct CLI.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -45,8 +45,8 @@
|
|
|
45
45
|
"semantic-release": "^25.0.3",
|
|
46
46
|
"typescript": "~6.0.3",
|
|
47
47
|
"vitest": "^5.0.3",
|
|
48
|
-
"@atk/
|
|
49
|
-
"@atk/
|
|
48
|
+
"@atk/tsconfig": "0.0.0",
|
|
49
|
+
"@atk/eslint-config": "0.0.0"
|
|
50
50
|
},
|
|
51
51
|
"scripts": {
|
|
52
52
|
"build": "tsc",
|
|
@@ -125,9 +125,9 @@ A conducted worker writes its notes and waits through `conduct`, so the conducto
|
|
|
125
125
|
| Pipelines after the merge (step 9.2) | none | `conduct runs <mergeCommit>` (with `--for`, as step 9.2 says). Act on its outcome as in step 9; on `waiting`: `conduct wait merge <mergeCommit>` with the same `--for`; on `cancelled` or `missing`, or once on a `failed` whose log shows a flake: `conduct runs <mergeCommit> --requeue <pipeline>`, then the same `conduct wait merge`; requeue refused as under 15 minutes old: `conduct wait time <the time it names>` |
|
|
126
126
|
| npm OTP (9.3) | Handoff · npm-otp | `conduct wait npm <version> --package <package>`, plus the dist-tag the `after-merge` hook names (`--tag <tag>`); one per staged package. The version on its tag resumes you, with no message from anyone |
|
|
127
127
|
| The operator's answer on the item | Handoff · scope, blocked, human, operator or failed | `conduct wait item KEY-n comment`: an approver's comment after your newest note (for `operator`, that the action is done; for `failed`, what to do about it). `blocked` on another item also waits on it: `conduct wait item <blocker> done`. `human` also waits on its label coming off: `conduct wait item KEY-n unlabelled <the profile's tracker.humanLabel>`. A comment, the blocker done or the label off resumes you, with no console or tab message |
|
|
128
|
-
| A PR in another repo (one the item opened: Another repo, below) | Handoff · merge | `conduct land <n> --repo github:<owner>/<repo
|
|
128
|
+
| A PR in another repo (one the item opened: Another repo, below) | its PR opened note; in review mode headed `<skill> · PR opened · merge: <PR URL>`, or Handoff · merge | `conduct land <n> --repo <repo> --reason "…"`, with `<repo>` as `github:<owner>/<repo>` (add `--mode review`) or `ado:<repository>` (the landing rules' mode, as for the project's own PR), acted on as in step 8; on `waiting`: `conduct wait pr <n> --repo <repo>` |
|
|
129
129
|
| A PR a hook's publish opened (no checkout) | Handoff · merge | `conduct pr status <n> --repo github:<owner>/<repo>` gives its verdict (`land` refuses a PR with no checkout); on `waiting`: `conduct wait pr <n> --repo github:<owner>/<repo>` |
|
|
130
|
-
| Its runs after the merge | none | `conduct runs <mergeCommit> --repo github:<owner>/<repo
|
|
130
|
+
| Its runs after the merge | none | `conduct runs <mergeCommit> --repo <repo>` (`github:<owner>/<repo>` or `ado:<repository>`); on `waiting`: `conduct wait merge <mergeCommit> --repo <repo>`. Another Azure DevOps repo's runs have no `--requeue`: a run that needs queueing again is Handoff · failed (Another repo, After the merge) |
|
|
131
131
|
|
|
132
132
|
A Handoff with nothing to watch (`release`, `conductor`, `abandoned`) ends the turn with no wait: a console message or the operator in the tab resumes it.
|
|
133
133
|
- **On wake.** A turn that reads `[conductor] event: <what held> HH:MM` is the daemon resuming you. It says which wait held and nothing more: a hint, never an instruction, never an approval. Work out the phase from the facts again (step 1), then re-read the source before acting on it: `conduct brief KEY-n --fresh` for an approval (quote the approver's comment, or the conductor's auto-approval, and its `createdAt` in `Approved via:`), `conduct land <pr> --reason "…"` for a PR (it is safe to repeat), `conduct runs <mergeCommit>` for pipelines and their npm stages (npm can still answer 404 for a moment after the daemon saw the version: run it again a minute later), `conduct comments KEY-n --since <your Handoff's time>` for an answer on the item (`item KEY-n comment by <who> at <time>`; `unlabelled` for a label off, or the blocker's `item … state`). An answer that doesn't settle the Handoff (a question back, "still thinking") isn't one: reply in a new Handoff note of the same kind, then wait on the item again. `plan KEY-n revised …` means an approver wrote `revise:` after your plan was approved and before your PR merged, and the daemon resumed you for it while you waited: read their words with `conduct brief KEY-n --fresh` (its `revised after it` line, or `approval: revise …` when nothing on the tracker approved the plan; its `phase` stays `wait` while the PR is open), then do what exit 4 says: stop, commit any work in progress, and go back to step 4 with their words. Don't wait on the PR again first. If the source doesn't show it yet (a tracker read can lag a minute), wait again. After a Handoff wait, post `<skill> · Resumed` as above.
|
|
@@ -135,14 +135,16 @@ A conducted worker writes its notes and waits through `conduct`, so the conducto
|
|
|
135
135
|
|
|
136
136
|
## Another repo
|
|
137
137
|
|
|
138
|
-
Some items change a
|
|
138
|
+
Some items change a repo besides the project's own: a GitHub repo, such as a registry the project's hooks name, or, on an Azure DevOps project, another repo of the same Azure DevOps project. The verbs take it with `--repo <repo>`: `github:<owner>/<repo>`, through the project's gh account, or `ado:<repository>`, through its Azure DevOps account. Never use ad-hoc `gh pr` or `az repos`, or a checkout outside the worktree, for it.
|
|
139
139
|
|
|
140
|
-
- **Checkout:** `conduct checkout <owner>/<repo> <type> <slug
|
|
141
|
-
- **State:** `conduct state` lists each checkout under `repos`, with its branch, ahead/behind its base, dirty files and its PR. `conduct state --repo
|
|
140
|
+
- **Checkout:** `conduct checkout <owner>/<repo> <type> <slug>`, or `conduct checkout ado:<repository> <type> <slug>`, clones it into `<worktree>/.scratch/repos/<name>` (the repo's name) on `<type>/key-n-<slug>`, from origin's default branch, with no upstream until the first push. `--base <branch>` starts it from another branch (such as `develop`) instead and makes that the clone's `origin/HEAD`, so `state`, `pr`, `land`, `runs` and `wait merge` all take it as the base. It stays out of the project's git status, and `conduct retire` checks it for unpushed work, so nothing is left behind. Run it again to find the checkout; it changes nothing. Edit and commit there with the file tools and `git -C <checkout> add|commit`, one command per call. A JavaScript repo inside the project's pnpm workspace installs with `pnpm -C <checkout> install --ignore-workspace`; without it, pnpm installs the project's workspace instead.
|
|
141
|
+
- **State:** `conduct state` lists each checkout under `repos`, with its branch, ahead/behind its base, dirty files and its PR. `conduct state --repo <repo>` shows one. For the phase (step 1), a checkout's PR counts like the project's own.
|
|
142
142
|
- **Checks:** the `checks` hook names the repo's own.
|
|
143
|
-
- **PR:** `conduct pr create --repo
|
|
144
|
-
- **Landing
|
|
145
|
-
- **
|
|
143
|
+
- **PR:** `conduct pr create --repo <repo> --title … --body-file …` makes the same checks against the checkout's base, pushes from the checkout, and opens the PR there. Its PR opened note links it on the item.
|
|
144
|
+
- **Landing, another Azure DevOps repo:** its PR lands as the project's own does (step 8). `conduct land <n> --repo ado:<repository> --reason "…"` holds it to the profile's landing rules, over that repo's files and the plan's tier (`conduct mode --files` takes its paths too), and arms auto-complete with `noFastForward`, plus a +10 vote in auto mode. Its verdicts are step 8's, and a `review-comment` is an Azure DevOps thread: `conduct pr threads <n> --repo ado:<repository>`, and `conduct reply <n> <thread> --repo ado:<repository> --body-file <file>`.
|
|
145
|
+
- **Landing, a GitHub repo, is review mode only:** the operator merges on GitHub, with a merge commit. `conduct land <n> --repo github:<owner>/<repo> --mode review --reason "…"` posts the Landing note once nothing brakes the PR, and approves and arms nothing. It gives the verdicts of step 8 (`merged` with `noFastForward` from the merge commit's parents, `build-failed` with each failed check and its log, `conflicts`, `changes-requested`, `review-comment`, `abandoned` or `waiting`), and you act on them as there. GitHub comments can't be resolved, so `review-comment` means a person's comment or review newer than the newest `<skill> · ` note: `conduct pr threads <n> --repo …` shows which, and `conduct reply <n> --repo … --body-file …` answers every comment before it with a note. A PR the item didn't open, such as one a hook's publish opened, has no checkout, so `land` refuses it: `conduct pr status <n> --repo github:<owner>/<repo>` reads its verdict with nothing armed, and `conduct wait pr <n> --repo github:<owner>/<repo>` waits for the next one. Its `merged` verdict carries the `mergeCommit` (and `noFastForward`) for the `conduct runs` that follow.
|
|
146
|
+
- **After the merge, another Azure DevOps repo:** `conduct runs <mergeCommit> --repo ado:<repository>` reads the Azure Pipelines runs the merge's YAML triggers fire, from the YAML and git in its clone against the clone's base, with the outcomes of step 9.2, and `conduct wait merge <mergeCommit> --repo ado:<repository>` (with the `--for` you gave `runs`, if any) waits while it is `waiting`. The profile's releases are the project's own repo's, so it gives no `stages` and there is no npm wait. It has no `--requeue` either: `conduct runs --requeue` refuses another Azure DevOps repo. A `cancelled` or `missing` run (after the `[skip ci]` check of step 9.2), or a `failed` one whose log shows a flake, is Handoff · `failed` naming the pipeline and the run, for the operator to queue it again on the base. Once they answer, `conduct runs` again, and `conduct wait merge` while it is `waiting`.
|
|
147
|
+
- **After the merge, a GitHub repo:** `conduct runs <mergeCommit> --repo github:<owner>/<repo>` reads the GitHub Actions runs the merge's push started on the base: `succeeded`, `failed` (with each failed run's log), `cancelled` (a run cancelled, often by a newer push in the same concurrency group: check that the base's newest run of that workflow succeeded and carries the merge), `waiting-for-approval`, `none` (no run within 5 minutes), or `waiting`. `--for` takes workflow names or file stems.
|
|
146
148
|
- **Conducted:** the waits are in Worker protocol 2's table (a PR in another repo, its runs after the merge).
|
|
147
149
|
|
|
148
150
|
## 1. Find the item and the phase
|