jbr870/devwork-skills

Fork 0

/develop: scope the per-unit gate to the packages the unit touched #41

New issue

Closed

opened 2026-08-14 13:01:47 +00:00 by jbr870 · 1 comment

jbr870 commented

2026-08-14 13:01:47 +00:00

Owner

Rank 4 of 13 in #37 · est. saving ~40m

Evidence

Inside /develop's 257 minutes, 62 (24%) were the lead re-running test suites. The full
pnpm test suite (~6 min, 4,187 tests at the time) ran after every one of six work units —
seven runs including the flake re-run — plus the 21-minute browser sweep.

Timestamps of the full-suite runs (UTC): 11:37–11:42, 12:06–12:11, 13:05–13:11, 13:41–13:47,
13:48–13:53 (re-run to disprove a flake), 14:17–14:23, 15:02–15:08.

Only 160 of the 257 minutes were agents writing tests or code.

What happens now

The per-unit verification step tells the lead to re-run the project's verification commands. In a
monorepo that means the whole workspace, for a unit that touched one package.

Proposed change

Scope the per-unit gate to the package(s) the unit touched, determined from the unit's declared
file boundaries. Keep the full workspace suite for the cross-unit verification at the end of the
phase, which already exists and already provides the integration signal.

This is the vitest half of the same rule as #38 (the Playwright half); they should be
written as one two-tier gate policy rather than two unrelated edits.

Acceptance

develop/SKILL.md states the narrow per-unit gate and the wide cross-unit gate separately.
A six-unit run executes the full workspace suite once, not seven times.
A unit that touches two packages runs both.

**Rank 4 of 13** in #37 · est. saving **~40m** ## Evidence Inside `/develop`'s 257 minutes, **62 (24%) were the lead re-running test suites.** The full `pnpm test` suite (~6 min, 4,187 tests at the time) ran after **every one of six work units** — seven runs including the flake re-run — plus the 21-minute browser sweep. Timestamps of the full-suite runs (UTC): 11:37–11:42, 12:06–12:11, 13:05–13:11, 13:41–13:47, 13:48–13:53 (re-run to disprove a flake), 14:17–14:23, 15:02–15:08. Only 160 of the 257 minutes were agents writing tests or code. ## What happens now The per-unit verification step tells the lead to re-run the project's verification commands. In a monorepo that means the whole workspace, for a unit that touched one package. ## Proposed change Scope the per-unit gate to the **package(s) the unit touched**, determined from the unit's declared file boundaries. Keep the full workspace suite for the cross-unit verification at the end of the phase, which already exists and already provides the integration signal. This is the vitest half of the same rule as #38 (the Playwright half); they should be written as one two-tier gate policy rather than two unrelated edits. ## Acceptance - `develop/SKILL.md` states the narrow per-unit gate and the wide cross-unit gate separately. - A six-unit run executes the full workspace suite once, not seven times. - A unit that touches two packages runs both.

jbr870 added the

labels

2026-08-14 13:01:47 +00:00

jbr870 referenced this issue

2026-08-14 13:02:37 +00:00

Feature-230 time study: 13 ranked pipeline-efficiency changes #37

jbr870 referenced this issue

2026-08-14 13:02:38 +00:00

Feature-230 time study: 13 ranked pipeline-efficiency changes #37

jbr870 referenced this issue from a commit

2026-08-25 09:25:35 +00:00

develop+qa: split the verification gate into narrow per-unit and wide phase-boundary tiers

jbr870 closed this issue

2026-08-25 09:25:35 +00:00

jbr870 referenced this issue

2026-08-25 09:26:05 +00:00

/develop + QA: run the full browser suite at phase boundaries, not after every unit and every fix round #38

jbr870 commented

2026-08-25 09:26:21 +00:00

Author

Owner

/meta-amend outcome — amended

Addressed as one two-tier gate policy together with #38, exactly as this issue asked ("they should be written as one two-tier gate policy rather than two unrelated edits"). Commit 7f75154 on main. Full write-up on #38; the vitest half in brief:

Verified at HEAD (`7453ac5`)

develop/SKILL.md's Implementer prompt said "4. Run the full test suite to check for regressions" with a matching checklist row — the whole workspace, for a unit that touched one package. 3.7's cross-unit verification already ran the wide suite, so the per-unit run was re-proving it N times.

The amendment

Narrow per-unit gate: the Implementer runs the project's verification commands scoped to its declared file boundaries — the package(s)/area(s) the unit touched, plus this feature's own end-to-end specs. A unit spanning two packages runs both (stated explicitly). Still a real gate, not advisory.
Wide cross-unit gate: 3.7 is named as the wide tier and the one place in the phase where everything runs, including the full browser suite the per-unit gates deliberately skipped.
Both tiers are defined once, in a "The two verification tiers" block at the top of Phase 3, so the Implementer prompt and 3.7 reference one statement rather than each carrying its own.
Scoping mechanism stays a project declaration (workspace filter, path/pattern argument, tag) per the repo's no-hardcoded-stack rule; "run whole" is written as the explicit fallback for runners that cannot scope, never the default.

Gate

scripts/lint-conventions.sh — clean.

Desk-check against the originating scenario (verity #230)

Six work units, seven full workspace-suite runs (62 of /develop's 257 minutes were the lead re-running suites). Under the amended text each unit runs only its touched package(s) plus the feature's specs, and the workspace suite runs once, at 3.7 — the acceptance criterion ("a six-unit run executes the full workspace suite once, not seven times") is met, and a two-package unit running both is stated in the text.

What validates it next

The next dogfooded feature with 3+ work units in a multi-package workspace. The signal to watch is a unit closing green under the narrow gate and then failing at 3.7 — that would mean the file-boundary scoping is too tight, not that the tiering is wrong.

## /meta-amend outcome — amended Addressed as **one two-tier gate policy together with #38**, exactly as this issue asked ("they should be written as one two-tier gate policy rather than two unrelated edits"). Commit `7f75154` on `main`. Full write-up on #38; the vitest half in brief: ### Verified at HEAD (`7453ac5`) `develop/SKILL.md`'s Implementer prompt said *"4. Run the full test suite to check for regressions"* with a matching checklist row — the whole workspace, for a unit that touched one package. 3.7's cross-unit verification already ran the wide suite, so the per-unit run was re-proving it N times. ### The amendment - **Narrow per-unit gate:** the Implementer runs the project's verification commands **scoped to its declared file boundaries** — the package(s)/area(s) the unit touched, plus this feature's own end-to-end specs. A unit spanning two packages runs both (stated explicitly). Still a real gate, not advisory. - **Wide cross-unit gate:** 3.7 is named as the wide tier and the one place in the phase where everything runs, including the full browser suite the per-unit gates deliberately skipped. - Both tiers are defined once, in a *"The two verification tiers"* block at the top of Phase 3, so the Implementer prompt and 3.7 reference one statement rather than each carrying its own. - Scoping mechanism stays a project declaration (workspace filter, path/pattern argument, tag) per the repo's no-hardcoded-stack rule; "run whole" is written as the explicit fallback for runners that cannot scope, never the default. ### Gate `scripts/lint-conventions.sh` — clean. ### Desk-check against the originating scenario (verity #230) Six work units, seven full workspace-suite runs (62 of `/develop`'s 257 minutes were the lead re-running suites). Under the amended text each unit runs only its touched package(s) plus the feature's specs, and the workspace suite runs **once**, at 3.7 — the acceptance criterion ("a six-unit run executes the full workspace suite once, not seven times") is met, and a two-package unit running both is stated in the text. ### What validates it next The next dogfooded feature with 3+ work units in a multi-package workspace. The signal to watch is a unit closing green under the narrow gate and then failing at 3.7 — that would mean the file-boundary scoping is too tight, not that the tiering is wrong.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jbr870/devwork-skills#41

No description provided.

Rows
Columns

/develop: scope the per-unit gate to the packages the unit touched #41

Evidence

What happens now

Proposed change

Acceptance

/meta-amend outcome — amended

Verified at HEAD (7453ac5)

The amendment

Gate

Desk-check against the originating scenario (verity #230)

What validates it next

Verified at HEAD (`7453ac5`)