@drawbridge/drawbridge-agents 0.1.90 → 0.1.91
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.
|
@@ -41,9 +41,9 @@ Wait for both answers. Never guess either name. The developer still assigns the
|
|
|
41
41
|
|
|
42
42
|
- every unknown from every story, **each with the fix you recommend**: "I recommend <the option>, because <the reason>." The recommendation comes from having read the code the subtask touches (the files the graph named, opened whole) and from what apps like Drawbridge commonly do for the same thing, and it picks the best experience for the person using the product. That goes for every aspect of the platform, not only screens: a feature, a price or plan rule, a design, a message, a default, a limit. A question without a recommendation reads as a question nobody has thought about (Darren, 2026-10-22: "recommend the fix as well. This way I know you've reviewed the code and considered the best approach. We should always be looking at what is the best user experience as well as what is common for apps like ours"). When the recommendation needs a fact you do not have, say which, and still name the option you would take;
|
|
43
43
|
- nothing about who reviews or tests: both were answered at line 1;
|
|
44
|
-
- **a package publish, if any subtask names `@drawbridge/components` or `@drawbridge/drawbridge-utils`**, as a statement, not a question: this release publishes a package; the developer named above publishes it. The package is built first and gets its own pull request to the package's `main`; the end list (line 5) hands the developer the merge and the
|
|
44
|
+
- **a package publish, if any subtask names `@drawbridge/components` or `@drawbridge/drawbridge-utils`**, as a statement, not a question: this release publishes a package; the developer named above publishes it. The package is built first and gets its own pull request to the package's `main`; the end list (line 5) hands the developer the merge and the tag to push; the skill then bumps the pin in every consumer, and the app pull requests open after that, once the publish is done. Line 4 step 2 is the exact sequence.
|
|
45
45
|
|
|
46
|
-
**Publishing is settled; never ask about it.** The developer publishes every package
|
|
46
|
+
**Publishing is settled; never ask about it.** The developer publishes every package by merging its version bump to `main` and pushing the tag `v<version>` (`git checkout main && git pull && git tag v<version> && git push origin v<version>`); GitHub Actions (`.github/workflows/publish.yml`, since Butterscotch 2026-10-23, task 1218041740718540) builds, runs the tests and publishes through npm trusted publishing, so no npm token exists anywhere and the registry shows the publisher as "GitHub Actions" (proven with stripe 0.1.56). The workflow refuses a tag that differs from `package.json` or is not on `main`. The hand path, `git pull && npm run build` on `main` with the developer's one-time password, still works as a fallback. Agents hold no npm token and never will. So the skill never asks who publishes, whether to publish, whether it may publish, or how: it writes the one command into the end list as an instruction to the developer and waits for `npm view` to show the version (Darren, 2026-10-22: "I get a lot of questions in the release about npm publishing etc, lets make sure that it's clear that the developers do the publishing so that these go away").
|
|
47
47
|
|
|
48
48
|
Wait for the yes. Nothing below runs before it. From the yes to the end list, the run is unattended: the next section says what that means.
|
|
49
49
|
|
|
@@ -76,7 +76,7 @@ All work on the release branches against the **Local** database. Develop and its
|
|
|
76
76
|
2. **Package first, and the publish never blocks.** Every subtask that touches `@drawbridge/drawbridge-utils` or `@drawbridge/components` is built before any app subtask, so the package is finished and its pull request ready when the end list goes out, and the build never pauses for it (Darren, 2026-10-22: "I had to wait a while for the publishing code to be written"; "the publish step includes merging each npm package to main, and bumping the pin(s)"). The whole package step, per package, utils before components (components peer-depends on utils):
|
|
77
77
|
1. Build the package subtasks on `feature/<id>` in that package, tests first, `npm test` and `npm run test:app` (components) green, the two review passes.
|
|
78
78
|
2. Bump the package's own version in its `package.json` (patch), commit, push, and open its pull request to the package's `main` (`gh pr create --base main …`), assigned to the developer from line 2. Nothing is posted to Asana yet; the link goes into the end list.
|
|
79
|
-
3. Write the publish instruction into the Parked section, addressed to the developer from line
|
|
79
|
+
3. Write the publish instruction into the Parked section, addressed to the developer from line 1, as one numbered item with the exact words: merge that pull request, then from the package checkout: `git checkout main && git pull && git tag v<version> && git push origin v<version>`; the Publish workflow does the rest, and `npm view <package> version` shows it within a few minutes (by hand if the workflow fails: `npm run build` on `main`). It is an instruction, not a question, and it goes out at line 5, never now. No question about publishing is ever put to anyone (line 2).
|
|
80
80
|
4. **Keep going** on the app subtasks. For one that needs the new package code, `npm link` the local package checkout into the app worktree so it is written and tested against it now.
|
|
81
81
|
5. When `npm view <package> version` shows the new version (after the person has published from the end list): bump the pin to that exact version in **every consumer in the family**, not only the release's (Darren, 2026-10-22: "Once a package is published, all consumer pins should also be updated"; pins are version-exact family-wide, `conventions/drawbridge-packages.md`). One command does it: `npx drawbridge-agents-bump <package> <version>` (from any family checkout; `--dry` lists the consumers first) finds every consumer, keeps each one's field, installs the exact version so the lockfile names it, commits "<package> <version>" and pushes each repo's current branch. Before running it, the release's own consumers must have their `feature/<id>` branch checked out (the worktrees), so they take the bump there, while every other consumer takes a pin-only commit on its integration branch. Unlink first where a worktree was linked; run the tests after. A sibling package bumped this way is itself published by the same steps before the apps that depend on it.
|
|
82
82
|
6. No app pull request opens while a pin still names a version the registry does not have.
|
|
@@ -127,7 +127,7 @@ The skill does none of this. For the record, so the skill can answer "what is th
|
|
|
127
127
|
## What the skill never does
|
|
128
128
|
|
|
129
129
|
- Push `main`, deploy production, write to the production database, publish a package, merge a pull request, assign the QA person or move the task to QA or Approved. Those are a developer's or a tester's lines. On dev the skill writes nothing of its own either (the refresh only READS dev to copy it into Local); the dev migration runs on a developer's explicit instruction, by the developer or by an agent they ask.
|
|
130
|
-
- Ask anything about npm publishing: who, whether, how, or for permission. The developer publishes, always; the skill hands them the one command in the end list and waits for the registry.
|
|
130
|
+
- Ask anything about npm publishing: who, whether, how, or for permission. The developer publishes, always, by pushing the version tag; the skill hands them the one command in the end list and waits for the registry.
|
|
131
131
|
- Name a reviewer, a tester or a release scope that nobody told it; the people are asked at line 1, the scope at line 2. The window is the developer's at line 9; the skill asks for it never.
|
|
132
132
|
- Name an organization in a test list. A developer or a tester opens one that has the features the list names; nobody can guess which they will use.
|
|
133
133
|
- Write a release document, branch or migration under any name but the Asana id.
|
|
@@ -2,8 +2,24 @@
|
|
|
2
2
|
|
|
3
3
|
Conventions for working on the `@drawbridge/*` npm packages
|
|
4
4
|
(`drawbridge-utils`, `drawbridge-components`, `drawbridge-mongodb`,
|
|
5
|
-
`drawbridge-redis`, `drawbridge-stripe`, `drawbridge-
|
|
6
|
-
|
|
5
|
+
`drawbridge-redis`, `drawbridge-stripe`, `drawbridge-telemetry`, `drawbridge-agents`)
|
|
6
|
+
and the apps that consume them. `drawbridge-shopify` is retired: the repo was archived
|
|
7
|
+
on GitHub and `@drawbridge/shopify` deprecated on npm (2026-09-13, "use
|
|
8
|
+
@drawbridge/drawbridge-utils/shopify/*"); never pin it.
|
|
9
|
+
|
|
10
|
+
## Publishing
|
|
11
|
+
|
|
12
|
+
**A publish is a tag push (since 2026-10-23).** Merge the version bump to `main`, then from
|
|
13
|
+
the package checkout `git checkout main && git pull && git tag v<version> && git push origin
|
|
14
|
+
v<version>`. Every package's `.github/workflows/publish.yml` runs on `v*` tags: it refuses a
|
|
15
|
+
tag that differs from `package.json` or is not on `main`, runs `npm ci`, `npx tsup` and
|
|
16
|
+
`node --test`, then `npm publish --ignore-scripts` through npm trusted publishing (OIDC,
|
|
17
|
+
`id-token: write`, npm 11). No npm token is stored anywhere; the registry records the
|
|
18
|
+
publisher as "GitHub Actions" (first proven with stripe 0.1.56, run 39975659406). The
|
|
19
|
+
trusted publisher for each package is configured on npmjs.com by Darren. A developer pushes
|
|
20
|
+
the tag; an agent never does.
|
|
21
|
+
|
|
22
|
+
The hand path below still works as a fallback when the workflow fails.
|
|
7
23
|
|
|
8
24
|
## Build + publish script
|
|
9
25
|
|
package/package.json
CHANGED