@drawbridge/drawbridge-agents 0.1.78 → 0.1.79
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.
|
@@ -29,17 +29,17 @@ Read the release task and every subtask through `drawbridge-tests/lib/asana.js`
|
|
|
29
29
|
For every subtask, find or write the story (`drawbridge-feature` step 1). Then ONE numbered list to the person who started the release, each item three plain sentences (`conventions/rules.md` rule 7), holding:
|
|
30
30
|
|
|
31
31
|
- every unknown from every story;
|
|
32
|
-
- **who on the development team takes the pull requests
|
|
32
|
+
- **who on the development team takes the pull requests**: their GitHub username (for the pull requests) and their Asana name (for the task). Asked now so nobody needs to be present between lines 3 and 5. Never guess a reviewer;
|
|
33
33
|
- **a package publish, if any subtask names `@drawbridge/components` or `@drawbridge/drawbridge-utils`**, in these words: this release publishes a package; the package is built, reviewed and merged to the package's `main` first; the person publishes it when asked (the skill cannot), the publish needs the one-time password until the automation token (queue task 1218041740718540) exists; the apps' pull requests cannot merge until their pin bumps resolve.
|
|
34
34
|
|
|
35
|
-
Wait for the yes. Nothing below runs before it.
|
|
35
|
+
Wait for the yes. Nothing below runs before it. A release that publishes a package stops once more, at the publish (line 4 step 2); everything else between lines 3 and 5 runs without anyone present.
|
|
36
36
|
|
|
37
37
|
## Line 3: Building
|
|
38
38
|
|
|
39
|
-
1.
|
|
40
|
-
2. `release/<id>` in every repo a subtask touches, off `develop` (components and utils off `main
|
|
39
|
+
1. **One release at a time.** List the project's tasks (`GET /projects/1219601041167594/tasks?opt_fields=name,memberships.section.name`). If any other release sits in Building, Review, QA or Approved, stop and say which one; only one release is being built or tested at a time (Darren, 2026-10-22). Then move this task to Building (`POST /sections/1219601033297172/addTask { task }`).
|
|
40
|
+
2. `release/<id>` in every repo a subtask touches, off `develop` (components and utils off `main`), each in a worktree under `/Users/darrenshea/Projects/.worktrees/<repo>-release-<id>` so no main checkout changes branch. **drawbridge-docs is the exception**: its `release/<id>` branch is made in the main docs checkout (docs is `main`-only and single-writer), because `npx drawbridge-agents-check-stories` reads nothing from a worktree path (Asana 1218852240225835). "Repo a subtask touches" includes docs, components and utils, not only the six apps.
|
|
41
41
|
3. Copy `drawbridge-docs/templates/release.md` to `releases/<id>.md`, fill Scope and Branches (reviewer from line 2), commit on the docs branch. The markdown is the one record; there is no json.
|
|
42
|
-
4.
|
|
42
|
+
4. If `drawbridge-api/release.json` does not already carry this task's link, write it, commit on the api's `develop` directly ("release <id>: band"), push; dev shows the yellow band above the account once the api redeploys. This is the only develop commit before the pull requests merge. When the link is already there, say so and move on.
|
|
43
43
|
5. If the release task has no subtask named "Marketing: What's new", create one.
|
|
44
44
|
|
|
45
45
|
## Line 4: build, on Local
|
|
@@ -49,9 +49,9 @@ All work on the release branches against the **Local** database. Develop and its
|
|
|
49
49
|
1. **Local up.** `npm run migrate -- refresh` in the api (copies dev into Local; `--dry` first), then `npm run local` in every app the release touches: dashboard 3000, share 3001, website 3002, api 4000, sync 4001, webhooks 4002. The scripts force the ports; nothing sets them.
|
|
50
50
|
2. **Package first.** A package subtask is built, reviewed and merged to the package's `main` before any app subtask that depends on it; when it is merged, ask the person to publish, then bump the pin on the apps' release branches.
|
|
51
51
|
3. **Per subtask**, on the release branch: read the story and the reference page, one graph query, failing test first where a suite exists, the change, `npm test` in that repo. One commit per subtask, its message starting with the subtask id.
|
|
52
|
-
4. **Migration.** If any subtask moves data, ONE file, `drawbridge-api/scripts/migration-<id>.js`, exporting `({ controller }) => async ({ dryRun, organization, ...args }) => counts`, holding every data step. It uses the controller only; a dry run refuses controller writes but cannot refuse a native `collection.drop()` or `dropIndex()`, so a step that drops anything branches on `dryRun` itself and reports what it would drop. Prove it on Local: `npm run migrate -- <id> --dry --env local`, then `--env local`. The runner prints the counts and writes `runs/<env>-<id>-<time>.json`; nothing copies them anywhere.
|
|
52
|
+
4. **Migration.** If any subtask moves data, ONE file, `drawbridge-api/scripts/migration-<id>.js`, exporting `({ controller }) => async ({ dryRun, organization, ...args }) => counts`, holding every data step. It uses the controller only; a dry run refuses controller writes but cannot refuse a native `collection.drop()` or `dropIndex()`, so a step that drops anything branches on `dryRun` itself and reports what it would drop. Anything a person must do around the run (export a collection and read it back before a drop, take a snapshot) is written into the release doc's Migrations section as the developer's steps, not into the file. Prove it on Local: `npm run migrate -- <id> --dry --env local`, then `--env local`. The runner prints the counts and writes `runs/<env>-<id>-<time>.json`; nothing copies them anywhere.
|
|
53
53
|
5. **Walk every touched app on Local**: `npm run walk -- --local <path or url>` from drawbridge-tests (dashboard at `localhost:3000`; sync must be running for anything live). Record what was seen; a label quoted later comes from this walk.
|
|
54
|
-
6. **QA agent on Local.** Dispatch `drawbridge-qa` with `target : local`, once per subtask that has a story (story paths, the SUBTASK id, the organization id
|
|
54
|
+
6. **QA agent on Local.** Dispatch `drawbridge-qa` with `target : local`, once per subtask that has a story (story paths, the SUBTASK id, the organization id: `APP_TEST_ORG_ID` in `drawbridge-tests/.env`, the e2e organization `fixtures/e2e-org.md` describes, present on Local because Local is a copy of dev). A subtask spanning many stories gets one report listing them all. Fix every fail on the release branch, redispatch, until every `drawbridge-tests/results/qa/<subtask id>.json` reads `fails : 0`. The fixes are commits in the same pull request; that is why the agent runs here and not on dev (Darren: "all agent work is done locally so the work and fixes get committed as part of the PR").
|
|
55
55
|
**Inbound webhooks are the exception.** Every Local Environment points `APP_CLIENT_WEBHOOKS_URI` at `http://localhost:4002`, which Shopify, Stripe and Twilio cannot reach, so a change to how a webhook is received or handled is marked in the Scope table as "webhooks: tested on dev" and the QA person checks it on dev in line 7.
|
|
56
56
|
7. **Review.** `superpowers:code-reviewer` against the stories, then `ponytail-review`, on each repo's diff.
|
|
57
57
|
8. Push the release branches.
|
|
@@ -89,11 +89,11 @@ The skill does none of this. For the record, so the skill can answer "what is th
|
|
|
89
89
|
|
|
90
90
|
## What the skill never does
|
|
91
91
|
|
|
92
|
-
- Push `main`, deploy production,
|
|
93
|
-
- Name a reviewer
|
|
92
|
+
- Push `main`, deploy production, write to the production or dev database (the refresh READS dev to copy it into Local, and that is all), 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.
|
|
93
|
+
- Name a reviewer or a release scope that nobody told it; both are asked in line 2. The tester is the developer's choice at line 6 and the window is the developer's at line 9; the skill asks for neither.
|
|
94
94
|
- Write a release document, branch or migration under any name but the Asana id.
|
|
95
95
|
- Build or run the QA agent against dev or develop before the pull requests merge. Local only.
|
|
96
96
|
|
|
97
97
|
## Section ids
|
|
98
98
|
|
|
99
|
-
Planned `1219601041167595`, Building `1219601033297172`, Review `1219762451512990`, QA `1219601033155111`, Approved `1219601033299066`, Released `1219601137919036
|
|
99
|
+
Releases project `1219601041167594` (workspace `15457086713130`): Planned `1219601041167595`, Building `1219601033297172`, Review `1219762451512990`, QA `1219601033155111`, Approved `1219601033299066`, Released `1219601137919036`. Application project, where the subtasks live: Complete `1213887707425532`.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Migrations live in the api
|
|
2
2
|
|
|
3
|
-
Every one-off migration and backfill
|
|
3
|
+
Every one-off migration and backfill is one file in `drawbridge-api/scripts/`, `migration-<release asana id>.js`, run through `drawbridge-api/migrate.js` and nothing else.
|
|
4
4
|
|
|
5
5
|
**The only exception is media processing** — work that needs ffmpeg or sharp to
|
|
6
6
|
open an image or a video. Those dependencies exist in `drawbridge-sync` and
|
|
@@ -46,23 +46,27 @@ quietly that dev served stale code the whole time.
|
|
|
46
46
|
return (`{ found, updated }` or whatever the counts are). The first run of a
|
|
47
47
|
migration is a read.
|
|
48
48
|
- Run it only through the runner. On a laptop, from the api checkout:
|
|
49
|
-
`npm run migrate -- <asana id> --dry --env dev`, then
|
|
50
|
-
`--organization <id> --env dev
|
|
49
|
+
`npm run migrate -- <release asana id> --dry --env dev`, then
|
|
50
|
+
`--organization <org id> --env dev`, then `--env dev`. There is no `--release`
|
|
51
|
+
flag: the migration id IS the release id.
|
|
51
52
|
No env file holds a value: the runner re-runs itself through `scripts/op.sh`
|
|
52
53
|
with the file `--env` names (`.env.local` / `.env.development`, two lines naming
|
|
53
54
|
a 1Password Environment), so the Environment is injected the way the servers
|
|
54
55
|
get it. It refuses the wrong cluster, hands a dry run a controller that throws
|
|
55
56
|
on any write, and writes the result to `runs/<env>-<fn>-<time>.json` (read the
|
|
56
57
|
file, never the console: `op run` conceals anything that looks like a secret).
|
|
57
|
-
- **Production
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
58
|
+
- **Production is run by a developer, by hand, from their api checkout** on
|
|
59
|
+
`main` at the promoted commit with a clean tree, with the api's two-line
|
|
60
|
+
`.env.production` beside `migrate.js` (Darren, 2026-10-22: "the api is the
|
|
61
|
+
only place that needs this, and locally it's there"):
|
|
62
|
+
`npm run migrate -- <release asana id> --env prod --dry --sha <promoted commit>`,
|
|
63
|
+
then the same without `--dry`. The runner refuses production off `main`, at
|
|
64
|
+
the wrong commit, or with `scripts/`, `lib/` or `migrate.js` modified. The
|
|
65
|
+
deployed api container can run it too (`doctl apps console <prod api app id>
|
|
66
|
+
drawbridge-api`, then the `op run --environment "$OP_ENVIRONMENT_ID" -- node
|
|
67
|
+
migrate.js …` form; the image carries `migrate.js` and `scripts/`, there is no
|
|
68
|
+
git, so `--sha` is proven against `APP_COMMIT_HASH`). An agent never runs it:
|
|
69
|
+
it hands the developer the command and verifies by reading afterwards.
|
|
66
70
|
- **The runner records nothing but its counts file**, and nothing else records
|
|
67
71
|
a run either: a developer runs the migration on dev after the pull request
|
|
68
72
|
merges and reads the printed result, and runs it on production from their
|
package/package.json
CHANGED