@drawbridge/drawbridge-agents 0.1.89 → 0.1.90
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.
|
@@ -9,7 +9,7 @@ One Asana release task is the unit. Its id names everything: the `feature/<id>`
|
|
|
9
9
|
|
|
10
10
|
The ten lines below are the release, as Darren confirmed them on 2026-10-22. The skill owns lines 1 to 5 and 10 and runs them without anyone present once line 2 has its yes. A developer owns 6 and 9. A QA person owns 7 and 8. The skill never does a developer's or a tester's line for them.
|
|
11
11
|
|
|
12
|
-
1. A person gives the skill the release task link. The skill runs the doctor, then asks two things before reading anything: who reviews and who tests
|
|
12
|
+
1. A person gives the skill the release task link. The skill runs the doctor, then asks two things before reading anything: who reviews and who tests.
|
|
13
13
|
2. The skill reads the task and subtasks, writes the stories, sends ONE numbered list and waits for the yes. The yes starts an unattended run.
|
|
14
14
|
3. Task → Building: branches, the release document, the band.
|
|
15
15
|
4. The skill builds on the release branches against the Local database, with the QA agent run locally. Nobody is asked anything; whatever needs a person is parked.
|
|
@@ -26,10 +26,12 @@ Read the release task and every subtask through `drawbridge-tests/lib/asana.js`
|
|
|
26
26
|
|
|
27
27
|
**Then, before the stories, ONE numbered list of two questions**, so the people are known before any work starts and nobody waits for the review to finish (Darren, 2026-10-23: "the first questions asked right away is who is the development reviewer and who is the qa specialist"; "Then any task questions can come after the initial review"):
|
|
28
28
|
|
|
29
|
-
1. Who on the development team reviews this release: their GitHub username (for the pull requests)
|
|
30
|
-
2. Who tests it: the QA person's Asana name
|
|
29
|
+
1. Who on the development team reviews this release: their GitHub username (for the pull requests) and their Asana name (for the task).
|
|
30
|
+
2. Who tests it: the QA person's Asana name.
|
|
31
31
|
|
|
32
|
-
|
|
32
|
+
No organization is asked for, and no test list names one. Nobody can guess which organization a developer or a tester will use, and a link to an organization they cannot open loses the whole session (Jaime, 2026-10-23: a link went to one of Darren's organizations). Each test list instead says what the organization must have (Darren, 2026-10-23: "Open an organization with the following features...").
|
|
33
|
+
|
|
34
|
+
Wait for both answers. Never guess either name. The developer still assigns the QA person at line 6; the name asked here is who that will be.
|
|
33
35
|
|
|
34
36
|
## Line 2: the one list
|
|
35
37
|
|
|
@@ -94,7 +96,7 @@ Only when every subtask that can be built has been built: each committed, `npm t
|
|
|
94
96
|
|
|
95
97
|
1. One pull request per repo: `gh pr create --base develop --head feature/<id> --title "Release <id>: <task name>" --assignee <developer> --reviewer <developer> --body <the Scope table, the per-subtask commits, the QA reports' paths, and the migration's dev command if there is one>`. Components and utils target `main`.
|
|
96
98
|
2. Every pull request body ends with the lane rule in one line: "Review any time, on the feature branch locally. Merge only when develop is free: one release on develop at a time, so this merges once the release before it is Released." Fill the Branches table in `releases/<id>.md` with the PR links; commit.
|
|
97
|
-
3. **How to test, on every subtask, for both readers.** Append to each subtask's description, under its Story lines, two headings (Darren, 2026-10-22: "steps for a developer to test via code, or locally, and a QA person's steps"). First, "Test locally (developer)": one numbered list with the branch to check out, the exact commands (`npm test` in the repo, the test file that proves the change, `npm run migrate -- <id> --dry --env local` when there is a migration, `npm run walk -- --local <path>` for a screen), the localhost
|
|
99
|
+
3. **How to test, on every subtask, for both readers.** Append to each subtask's description, under its Story lines, two headings (Darren, 2026-10-22: "steps for a developer to test via code, or locally, and a QA person's steps"). First, "Test locally (developer)": one numbered list with the branch to check out, the exact commands (`npm test` in the repo, the test file that proves the change, `npm run migrate -- <id> --dry --env local` when there is a migration, `npm run walk -- --local <path>` for a screen), and for a screen: "Open an organization with the following features: <what this subtask needs, e.g. a connected Shopify store, a giveaway with a published prize>" on `http://localhost:3000`, then the path inside it by screen name, and the result each command must print or show. Never a fixed organization id. Then, "Test on dev (QA)": one numbered list with the dev app to open first (dashboard `https://dev.dashboard.trydrawbridge.com/organizations`, then "Open an organization with the following features: <what this subtask needs>" and the screens by name from there, never a fixed organization id, a share page `https://<slug>.dev.drwbrdg.com/...`, the website `https://dev.trydrawbridge.com/...`, the components app `https://components.trydrawbridge.com/...`), then one action per step, then what the tester must see. Every label in it is quoted from the Local walk and the QA reports of line 4, never from memory (`conventions/walk-the-app.md`), with dev URLs in place of localhost. A migration subtask says what the tester checks after the developer's dev run. The words go through `humanizer`. Both lists are written here, after the build, because only then are the commands and labels known (Darren, 2026-10-22: "include steps on how to test in the respective development apps"). The pull request body and the release doc's QA table point at the subtasks for these steps rather than repeating them.
|
|
98
100
|
4. Attach every QA report's screenshots to the release task (`node lib/asana-attach.js <release id> <png>` from drawbridge-tests, one per scenario, named `<subtask id>-<scenario>.png`), because the reports under `results/qa/` are gitignored and exist only on the machine that ran them. Then put the PR links on the release task as ONE numbered list (`drawbridge-asana-comment`): this is the first Asana comment of the release, and the package pull request's link rides in it too. Assign the task to the developer and move it to Review (`POST /sections/1219762451512990/addTask`) only once every pull request is open, parked items included.
|
|
99
101
|
5. Stop. Report the PR links.
|
|
100
102
|
|
|
@@ -126,7 +128,8 @@ The skill does none of this. For the record, so the skill can answer "what is th
|
|
|
126
128
|
|
|
127
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.
|
|
128
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.
|
|
129
|
-
- Name a reviewer, a tester
|
|
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
|
+
- 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.
|
|
130
133
|
- Write a release document, branch or migration under any name but the Asana id.
|
|
131
134
|
- Build or run the QA agent against dev or develop before the pull requests merge. Local only.
|
|
132
135
|
|
|
@@ -99,7 +99,15 @@ skill) so it stops living only in tribal memory.
|
|
|
99
99
|
`APP_CLIENT_WEBHOOKS_URI`) → `buffer` doc → sync drain → platform-global suppression row;
|
|
100
100
|
api registers the number's SmsUrl at twilio connect (`lib/twilio.js`) and `scripts.js
|
|
101
101
|
registerTwilioWebhooks` backfills — a deployed webhooks route with unregistered numbers hears
|
|
102
|
-
nothing, silently.
|
|
102
|
+
nothing, silently. **Since Butterscotch (release 1219790090574059; sync 762fdd7, Darren
|
|
103
|
+
2026-10-23: an opt-out is the person's choice, not one address's) `canSend` gates the
|
|
104
|
+
PERSON, not only the address**: it reads the recipient's contact in the organization (found by
|
|
105
|
+
`canonical.emails`/`canonical.phones` or by `leads`) and blocks when any canonical or raw
|
|
106
|
+
address on that contact is suppressed for the channel. `lead` is optional, so every caller
|
|
107
|
+
that knows the lead passes it, or a returning person under a new mailbox passes until their
|
|
108
|
+
contact is rebuilt with the new address. The api's draw opt-out check
|
|
109
|
+
(`route/organization-campaign-draw.js` `optedOutLeads`) applies the same rule and must stay
|
|
110
|
+
in step with it; before Butterscotch both matched the lead's own canonical address only.
|
|
103
111
|
- **`audience` picks the FROM-address; `intent` picks the unsubscribe plumbing — and NOTHING
|
|
104
112
|
passes the suppression gate** (utils ↔ sync ↔ api). Every suppression source blocks every
|
|
105
113
|
lead-facing send, the winner claim included: api's draw route refuses up front ("Disqualify
|
|
@@ -88,8 +88,15 @@ await removeEntrant( seeded ); // when the walk is done
|
|
|
88
88
|
|
|
89
89
|
`seedEntrant` writes what the api's thin ingest writes — a zero-count lead and one submission
|
|
90
90
|
flagged pending — and waits for the sync worker to materialize the entries and every counter.
|
|
91
|
-
`removeEntrant` deletes the draws that picked the lead and then the lead
|
|
92
|
-
|
|
91
|
+
`removeEntrant` deletes the draws that picked the lead and then the lead, and lifts any denial a
|
|
92
|
+
walk made on the entrant, which outlives the lead by design (drawbridge-api `schema/denial.js`
|
|
93
|
+
keys moderation on the person's canonical identifiers, not the lead id, so no product cascade
|
|
94
|
+
removes it; since drawbridge-tests b081ac1, Asana 1219802418571685); sync's cascade does the
|
|
95
|
+
rest and each counter nets back to zero. **Every `walk+<tag>@…` address is ONE person** to
|
|
96
|
+
moderation and to consent, because `toCanonicalEmail` in utils `lib/email.js` strips the plus
|
|
97
|
+
tag before either looks a person up: a denial or an unsubscribe made on `walk+a@` also covers
|
|
98
|
+
`walk+b@`. Concurrent or later walks that must not share a moderation or consent state use
|
|
99
|
+
different base mailboxes, not different tags. A lead inserted with its subtotals filled in was
|
|
93
100
|
never counted on its campaign, so deleting it decremented Entries and Submissions below zero
|
|
94
101
|
(Asana 1218811920761541, 2026-09-23). Counters now floor at zero in sync, but the seed still
|
|
95
102
|
has to go through the worker or the counts on the walked screen are wrong.
|
package/package.json
CHANGED