This is the operating model a team adopts when it runs gstack under a Capy Captain: one person, one Captain thread that directs a crew, crew threads that each own a branch and stop at an unstamped READY, one controller that merges through trains, a daily flaky pass, a weekly release, and a scorecard that says whether the factory is getting better. It was written from two crews that ran it for a week on their own repositories (about 100 merges a week each) and from the recurring problems four Captains reported while doing so. Every path and check name below is configurable; nothing here depends on gstack's own repository.
Two layers, kept apart on purpose:
- Harness-generic (works in Claude Code, Codex and any host that reads the
SKILL.md files):
/ship,gstack-ship-queue,gstack-restamp,gstack-pregate, the ship receipt, the train protocol, the flaky-rerun rule,release-cut,gstack-factory-scorecard,/retro. - Capy-specific: the user-scope skill folder and its install check, the
Captain and its Drive, crew threads, automations,
tools.pr.create, the approvals relay. Each one is marked Capy below; the section at the end lists what is only Capy.
flowchart LR
P[Person] -->|plain-language asks and one-word answers| C[Captain thread]
C -->|briefs, slot calls| L1[Crew thread: branch A]
C --> L2[Crew thread: branch B]
C --> L3[Crew thread: branch C]
L1 -->|/ship, READY block with SHIP_RECEIPT| C
L2 --> C
L3 --> C
C -->|train build: one gate for up to 5 PRs| G[(Gate workflow)]
G -->|GREEN or RED with flake records| C
C -->|slot: stamp, verify, merge, verify| M[(main)]
M -->|Monday| R[Weekly release: tag, notes, stable]
G -.->|flake-records artifacts| F[Daily flaky pass]
M -.->|free-suite retries| F
M -.->|/retro Step 7.5| S[Factory scorecard]
Copy capy/skill/gstack/ from a gstack checkout into the person's user-scope
Drive as skills/gstack/ (SKILL.md, captain.md, scripts/install.sh).
Add to the user-scope AGENTS.md:
At the start of each session on a Capy cloud machine, load the user-scoped
gstackskill and perform its installation check before starting work. If the check fails, follow the skill's session-start steps. Treat a session with nogstack: okline from this machine as having no gstack: run no gstack workflow, claim none works, and report any blocker. Repeat this check on each separate task machine.
What that buys you: every thread runs bash scripts/install.sh --check [--for <skill>] first and reports exactly one trailer, gstack: ok <revision> for=<skill> or gstack: fail <ids>. The install is about 30 seconds cold
and prints the GSTACK_LAUNCH: assignments every later command needs
(docs/capy-install.md). A thread that runs /ship installs
with --for ship; a planning-only verdict (SKIP pins (planning-only)) does
not admit /ship, /review or /qa.
Two things the first week taught every crew:
- Most threads never install. The rule installs right before the first
workflow, so a thread that does not plan one never gets
/reviewor/investigateeither. If most threads in a project run a workflow, bake gstack into the project's Capy Setup snapshot instead (capy-install.md#bake-into-a-capy-snapshot): each session then pays only the check. - One revision per thread. Subagents on fresh machines install separately and can land one patch apart. Put the minimum revision your crew needs in the crew rules and have every first report quote the trailer, so a lane that is behind says so.
The harness reads four files from the repository. A team can adopt them one at a time; each is independent.
| File | Why | Without it |
|---|---|---|
.gstack/pregate.json |
Maps changed paths to test lanes, so /ship runs the tests that cover the diff and the remote gate selects correctly (docs/pregate.md) |
/ship fails every touched file with PREGATE_NO_LANE. Write it once, from one owner, before the crew starts. |
.gstack/ship-policy.json |
queue_mode, the train block (gate and free workflow names, the full-gate check, the train size and fill wait), the stamp files (docs/ship-policy.md) |
Per-PR queue; train … refuses with QUEUE_TRAIN_OFF. |
CHANGELOG.md + VERSION |
A stamp per merge and a weekly release with notes (docs/releases.md) | Skip the version and changelog steps; the train still works on the tree receipt. |
AGENTS.md validation discipline |
Diagnose before fixing, focused checks during repair, one full suite at the end on a frozen tree | Threads retry blindly and report passes from older revisions. |
A .github/workflows gate that the train can dispatch is the one hard
requirement for trains: a workflow that accepts workflow_dispatch with the
train nonce and publishes a check (full_gate_check) and a record artifact on
the train head. gstack's own evals.yml is the reference; a repository with a
plain test workflow sets gate_workflow to it and gets a train without paid
cases.
Create a Captain from the Capy app (New Captain) or with
tools.captain.create. Its Drive is mounted read-write on every crew thread;
this layout is what the crews converged on:
captain-<name>/
AGENTS.md the Captain's standing rules: mandate, severity bar, standing approvals, every decision quoted verbatim with its date
CREW.md the crew rules every thread reads at start (install check, validation discipline, READY shape, stamp-on-call, flaky rule, approvals)
DIGEST.md the state of the crew, "Needs you" first; rewritten, never appended
NOTES.md the Captain's running log
skills/ procedures the crew runs: merge-train/, captain-approvals/, and any repo-specific runbook
reports/<code>.md one per thread: Outcome, PR (with head SHAs), Needs, Cost, Lesson, Approvals
handoffs/ datasets and files the next thread needs (the flaky ledger lives here)
plans/ plans brought for approval
The phase-1 templates for these files (AGENTS.md, CREW.md, DIGEST.md, a
report, a READY block, an approvals table, a slot call) ship under
captain/templates/ with the /captain skill, and docs/captain.md
explains how the Captain runs a day. Drop the templates in, replace the
placeholders (repository, crew login list, gate workflow name, minimum
revision, who may approve what), and the crew has its rules before its first
thread starts. The approvals shape itself (plan asks with before → after, why,
cause, big decisions and a one-word default; a ## Approvals table in every
report and PR body) is the harness-generic part and is documented in
capy/skill/gstack/captain.md.
A lane (one crew thread, one branch) does this, in order. Every command is harness-generic; only the thread and the PR tool are Capy.
- Branch from the default branch, build, test with focused checks. Write
the CHANGELOG entry under
## [Unreleased]; leave VERSION at main's value. Never pre-pick a version. - Push the final head. Everything below binds to the pushed head; a later push invalidates the receipt, the pregate record and the review binding.
- Open the PR with the host's PR tool (Capy:
tools.pr.create, nevergh pr create, so CI and review callbacks reach the thread), base the default branch. - Run
/shipunattended with theGSTACK_LAUNCHassignments exported: it runs the pregate (on a machine under 8 cores the test tier needsgstack-pregate --stage tests --remote, about $0.06 on a Ubicloud VM or free locally for small selections), both reviews, the gate-integrity list, the docs audit, and writes the ship receipt into the PR body (gstack-ship-receipt write --pr <n>). Withqueue_mode: stamp-at-merge,/shipdoes not bump the version./shipnever merges and never merges main into the branch. - READY.
gstack-ship-queue ready --pr <n> --no-screen(after running the skill's own paid cases focused) or--screen(one paid screen on the merge SHA). Send the printed block as is:READY #<n> <head> STAMP_VERSION=unstamped, CI at that head,PREGATE: pass, the screen line andSHIP_RECEIPT: pr=<n> head=<head>. A block withSHIP_RECEIPT: noneis not READY. From now on the head is frozen: a push drops the PR from any train (QUEUE_TRAIN_MOVED) and the lane must READY again. - Post the READY block as a PR comment too. The Captain reads it in the thread; the scorecard (below) measures READY → merge from the first PR comment that carries it. A crew that only reports in-thread has no READY-to-merge number.
The controller (the Captain, or a thread it designates) does this; the
Captain's skills/merge-train/ runbook holds the crew's copy and
ship-policy.md#run-a-merge-train is the
reference:
gstack-ship-queue train build --prs 41@<sha>,42@<sha> --dry-run, then without--dry-run. Up to 5 READY pins, screened first; with fewer than 5 it waits until the oldest READY isfill_hoursold,--urgentfor one PR. Refusals happen before any spend: a moved head, a missing receipt, a fork head, a real conflict (the line names the PR and files; rebuild without it and send it back to its lane to merge main).train verdict: GREEN, possibly withFLAKY N(a case failed once and passed its one in-run rerun; that is green, and the flake record goes to the daily pass), RED (cases that failed twice: bisect on them, drop the attributed PR, or rebuild once after an all-green bisect, never more), or INCOMPLETE (one re-dispatch for an INFRA-only census).- Per slot, in order: call the lane ("#41 slot , base ,
order <…>"). The lane merges main if needed (CHANGELOG by section), runs
gstack-restamp --next --base main --pr 41 --expect-base <sha> --expect-order <…> --allow-repo-commands, commits only the stamp files, pushes, waits for required CI, and reportsREADY #41 <stamped sha> STAMP_VERSION=<X>. The controller runsgstack-ship-queue verify --pr 41 --train <nonce>, merges with the exact head (gh pr merge 41 --squash --match-head-commit <sha>, or--mergewhere the repository keeps merge commits), and verifies again. A stamp commit that holds anything beyond the stamp files failsverify --train, freezes the queue and costs a backstop gate. train prunewhen every slot has merged.
Who merges. One controller, never the lane. Both crews that ran this learned it the same way: a PR merged off a green list state whose gate never passed, and a stamp commit with one extra line that froze the queue.
The rule (set once by the owner and quoted in the crew rules): a case that fails on its own verdict is rerun once at the same tree, inside the same run. A pass is green with a flake record; a second failure is a real red; harness, INFRA and INCOMPLETE reds are never flakes. Nothing is retried twice, and no threshold, budget or trial count moves to manufacture a pass.
The pass reads two sources, the same two the scorecard counts:
- Paid: the gate workflow's
flake-records-a<attempt>artifact (flake-records.jsonl, one record per flaky case: case, kind, PR, head, run, both attempts, symptom, rerun cost). - Free: the free workflow's
flake-ledger-*artifacts (oneflaky-passline per file that failed and passed on the serial retry).
It appends each event to a ledger the crew can read (the crews keep it at
handoffs/flaky-ledger.md in the Captain's Drive: date, case, tier, PR and
head, both runs, a one-line symptom), ranks repeats first, and opens one fix
thread per day with the ledger's Open section as its brief. The fix thread
moves entries to Fixed (with the PR) or Won't fix (with the reason), never
deletes them. bun run test:health is the free weekly check on the free lane
(a file that flakes in more than 5% of main runs over at least 20 runs fails
it).
As a Capy automation (Capy): one automation, one schedule trigger a day in
the owner's timezone, prompt along the lines of "read the newest gate runs'
flake-records-a* artifacts and the free runs' flake-ledger-* artifacts
since the last pass, append new events to handoffs/flaky-ledger.md, rank
repeats first, start one fix thread with the Open section as its brief, and
report the count to the Captain". Pass thread: "this" to keep the history in
one place, and run it once by hand before enabling it.
.github/workflows/weekly-release.yml runs scripts/release-cut.ts every
Monday morning: it takes the newest green commit on main's first-parent history
(its required check succeeded, the backstop check succeeded, every check run
completed and none failed, no active freeze), tags it v<VERSION>, publishes a
GitHub Release whose notes are one line per CHANGELOG version since the
previous release, and fast-forwards stable. Team-mode installs follow
stable; gstack-config set update_channel main follows every merge. A
hotfix is --ref <sha on main>. Details and the "nothing green in the window"
failure mode: docs/releases.md. A repository adopting this
copies the workflow, sets its required check and backstop check names
(REQUIRED_CHECK, BACKSTOP_CHECK), and keeps the CHANGELOG headline
convention (docs/CHANGELOG_STYLE.md).
Watch for release starvation: when trains merge faster than the backstop settles, most main commits are superseded before they are gated and the week can end with no candidate. The fix is in tooling (accept a commit a green train record covers), not in holding slots by hand.
bin/gstack-factory-scorecard reads one window (default 7 days) from GitHub
through gh and prints a Markdown table plus a CSV; /retro runs it as
Step 7.5 when gh is authenticated. Read-only, no paid work; it downloads the
small verdict and flake artifacts, so a busy repository takes a few minutes
(--max-artifact-runs caps that). Every line prints its counting rule, and a
line whose input could not be read says unavailable (<reason>) rather than 0.
gstack-factory-scorecard --repo owner/name --since-days 7 \
[--crew login,login] [--gate-workflow evals.yml] [--free-workflow free-tests.yml] \
[--train-prefix train/] [--ready-marker 'READY #\d+|SHIP_RECEIPT:'] [--pass-marker '"passes": (\d+)|passes=(\d+)'] \
[--pass-cap 3] [--out-dir .context/factory-scorecard]--repo defaults to the origin remote's owner/name on github.com (or
GH_HOST) and is required without one. Each run writes this window's scorecard.md and scorecard.csv
to --out-dir and appends the same rows to trend.csv there, so a weekly
retro accumulates its own trend without renaming files.
| Line | How it is counted | What one of the best software factories would show |
|---|---|---|
| Merged PRs | merged_at in the window, base = default branch; crew by --crew logins, else author association OWNER/MEMBER/COLLABORATOR |
several merges a day, every day; outside contributions land in the same week |
| Lead time, created → merged | PR created_at to merged_at, median and p90 |
median under 24h, p90 under 3 days (DORA "elite" change lead time is under a day) |
| Lead time, READY → merged | first PR comment matching --ready-marker at or before merged_at; PRs with no such comment are left out and counted |
under 2h; every merged PR carries a READY comment |
| Review passes per PR | the largest count --pass-marker captures in the PR body (the ship receipt's "passes": N once /ship writes it) or a PR comment (passes=N, REVIEW_PASSES: N), median and p90, plus how many PRs sat at --pass-cap (3: pass 1 reviews the whole diff, later passes only the delta, a pass that finds nothing new is the exit) |
median 2 passes; none at the cap |
| Gate runs green / red / cancelled | completed runs of the gate workflow (workflow_dispatch by default; --gate-event any); cost from the run's report-verdict-a* artifact (collector-outcomes.json .verdict.costUsd), else the **$N** rule/judge cost or cost=$N line of the PR's verdict comment |
green on 95%+ of runs, cancelled near 0, cost known for every run |
| Known gate cost per merged PR | known cost / merged PRs; unknown-cost runs make it a floor | known, stable or falling week over week |
| Red-train rate | runs whose head branch starts with --train-prefix, cancelled excluded; red = conclusion other than success; red backstops and screens shown beside it |
under 5% (each red train is a bisect plus a rebuild, about two gates) |
| Flaky events | flake-records-a* records of the newest gate runs (count, known rerun spend) and flake-ledger-* entries of free runs on the default branch; a run whose artifacts cannot be read is counted and named, never scored 0 |
0 repeat cases; under 1 flaky case per 10 gates; free retries under 1% of runs |
| Issues opened / closed | GitHub search, created and closed in the window | closed ≥ opened; nothing severe older than a week |
| Releases cut | releases published in the window, drafts excluded | at least one tagged release a week, on schedule |
The third column is a bar, not a boast: it is what DORA's elite band and the best-run open source projects show, and it is in the table so a reader sees the gap next to the number.
Measured on gstack's repository with this tool for 2026-10-19 to 2026-10-26
(the first full week of trains and /ship-before-READY; 103 merged PRs, 77
gate runs, artifacts read for the newest 60):
| Line | gstack, that week | Against the bar |
|---|---|---|
| Merged PRs | 103 (crew 100, outside 3) | volume is there; outside contributions are few and are ported by the crew rather than merged from forks |
| Lead time, created → merged | median 7.9h, p90 23.7h | inside the bar on both |
| Lead time, READY → merged | no number: 0 of 103 PRs had a READY comment | the crew reports READY in-thread; step 6 above (post it on the PR) is what makes this measurable |
| Review passes per PR | no number: 0 of 103 PRs carried a pass count | the receipt's passes field lands with /ship's convergence rule; until then crews record the count in the READY block, and the marker reads it from a PR comment |
| Gate runs | 73 green / 4 red / 0 cancelled; known cost $1,628 on 59 of 77 runs | green rate 95%; cost unknown on 18 runs (screens that planned no cases, and runs older than the artifact cap) |
| Known gate cost per merged PR | $15.81 (a floor) | about $24 per train of up to 5 PRs, plus screens; one gate per PR would have been about $33 each |
| Red-train rate | 4% (1 red of 28 trains; 0 red backstop, 3 red screens) | inside the bar; the three red screens were one judge reading a moved file |
| Flaky events | 21 paid cases passed on their one rerun (rerun spend $10.72); 17 free-suite retries in 17 of 103 runs | above the bar on both: 0.27 flaky cases per gate against 0.1, and 17% of free runs retried against 1%. One family (ship-docsync-*) repeated three times in two days |
| Issues opened / closed | 50 / 56 | inside the bar |
| Releases cut | 1 (the first weekly release) | on schedule, with the starvation caveat above |
Read the gap honestly: lead time and throughput are where they should be, the
gate is green and its cost is mostly known, and flakiness is the line that is
not. The daily pass exists for exactly that line; the scorecard's job is to
show next week whether it moved. The inventory lane's per-PR baseline CSV in
the Captain's Drive (142 merged PRs over the eleven days before this window
closed) holds the longer history behind these numbers; from here on
trend.csv in --out-dir carries the weeks.
| Concern | Harness-generic (any host) | Capy-specific |
|---|---|---|
| Install and health | ./setup, gstack-doctor, gstack-upgrade |
the user-scope skill folder, scripts/install.sh --check and its trailer, the project Setup snapshot |
| Running a workflow | the SKILL.md files, GSTACK_SESSION_KIND=unattended, GSTACK_RESULT: lines |
the GSTACK_LAUNCH assignments, GSTACK_CAPY=1 and the capy-asks block, no enforced hooks (safety skills are advisory) |
| Approvals | gstack-approvals, gstack-owner-brief render --captain, the ## Approvals table |
the Captain relay (needs_you), the Captain drive approvals/ mirror |
| Pull requests | /ship, the ship receipt, gstack-pr-shots |
tools.pr.create (callbacks), tools.pr.uploadAsset (before/after images) |
| Merging | gstack-ship-queue (ready, train build, verdict, verify), gstack-restamp, gh pr merge --match-head-commit |
the controller is a Captain thread; slot calls are thread messages |
| Flaky pass | the rerun rule, flake-records-a* and flake-ledger-* artifacts, test:health |
the daily automation and the ledger in the Captain's Drive |
| Release | release-cut, weekly-release.yml, the stable channel |
nothing |
| Scorecard | gstack-factory-scorecard, /retro Step 7.5 |
nothing (the CSV can be kept in the Captain's Drive) |
| Memory | reports/<code>.md, DIGEST.md, the flaky ledger |
the Drive scopes they live in |
Two crews ran this a week on different repositories and kept different habits on a few points. Ship the one that fits the repository; both are supported.
| Point | Option A | Option B |
|---|---|---|
| Merge method | squash with --match-head-commit (one commit per PR; CHANGELOG merges by section) |
merge commit with --match-head-commit (keeps the lane's commits; history: merge in the policy) |
| Paid evidence per PR | one train gate covers up to 5 PRs; lanes choose --screen or focused own cases |
a full gate per PR at handoff, plus "gate-ahead": PR N+1 gates on (its branch + N's head) so N's merge needs no second gate |
| Reusing a gate | tree rule: a head whose diff from the gated tree touches only stamp files reuses the gate (gstack-tree-receipt) |
the same rule, checked by the controller with git diff <gated> <head> before every merge |
| Severe fixes racing for a slot | the next train, --urgent for one PR |
call the slot for all; the first complete READY wins and the rest restamp to the next patch |
| Cheap CI on PR pushes | free tests on every push; paid work only in trains and screens | a cheap tier on pushes, a full-ci label that dispatches the full suites on the exact head; the cheap tier is never merge evidence |
| Infra flakes | never rerun a harness/INFRA red; one re-dispatch for an INFRA-only census | one named infra flake (for example a known runner wedge) may be rerun once and must be stated in the READY; a second wedge escalates |
| Small fixes | one PR each, batched by the train | batched into wave PRs, since serial slots cost about 30 minutes each |
| After the merge | the main backstop gates any push a train did not cover, and freezes the queue on red | the controller watches main's test, e2e and release runs until the release publishes; a red main freezes the queue until root-caused |
| Severe triage | the Captain watches issues and PRs and starts a thread per unowned severe item | a scheduled severe sweep (every 4 to 8 hours) with a fixed severity bar, dedupe against owned lanes, one hotfix thread per batch |
| Contributor PRs | ported onto a crew branch with the author's commits kept and Co-authored-by; the fork PR is closed with a thank-you that links the port |
landed through a wave PR with "Contributed by @handle", Co-Authored-By and Supersedes lines |
| Privacy | the pregate's sealed-output and secret scans before every push | plus a per-user denylist grep (names, hostnames, identifying counts from private sources) before any public artifact |
Collected from the issue files five Captains wrote on 2026-10-26 after a week of running this harness on five repositories. Each is a limit of the platform or of the harness on it as of that date, with the workaround the crews use.
Install and versions
- Every machine, subagents included, needs its own install and trailer; a fresh machine spends 30 seconds to a few minutes on it, and crews with nine shard subagents per run pay it nine times. Workaround: bake gstack into the project Setup snapshot.
- Threads that plan no workflow never install, so
/reviewand/investigatego unused. Workaround: a crew rule that names the workflow each thread will run, or the snapshot. - gstack versions drift between machines in one thread (
behind=1on one, current on another); every minimum bump was a crew-wide broadcast (eight in ten days for one crew). Workaround: the minimum revision in the crew rules, quoted in every first report. - A reviewer installed
--for review-voiceis refused by every workflow and must reinstall--for <skill>when later asked to run one.
Machines and long work
- Machine sleep and restarts kill detached servers, local drivers and long
verify loops;
/tmpdoes not survive a wake. Workaround: watched background operations (they keep the machine awake), run directories under~/.capy/work, long drivers on a remote VM, one worktree per counted run. - Commits on a shared tree sweep up another subagent's uncommitted hunks. Workaround: one committer per tree.
- Capy's git wrapper forces the linked identity, so tests that set
GIT_AUTHOR_NAMEand assert on it fail on every Capy machine and pass in CI (gstack's owntest/gstack-retro-metrics.test.tsis one). Workaround: read those failures as environment, and run the free suite on a remote VM for acceptance. - A broken shell line can print the environment, keys included, into a tool
log. Workaround: never run
env,printenv,setorexportbare; check a secret as set or unset only (gstack's launch-env ratchet enforces this in its own files).
Pull requests and review
tools.pr.createwithoutindexorheadpublishes the primary checkout's branch, not a worktree's, and targets the configured base, which on a project that works off a non-default branch must be passed every time.- Capy's per-push automatic review plus
/ship's two review passes double the review time, and a review loop can run five or more cycles on a P0 as each push surfaces one new finding. Workaround: run the review voices before the first push; on a P0 fix only findings in the P0 path and defer the rest to a follow-up. - A clean review is not carried forward to a tree-identical merge head, which can sit "running" for ten minutes or more.
- PR watches and CI callbacks fire only for repositories in a Capy project; a thread waiting on a repository outside one sleeps until a timer wakes it.
- No per-subagent cost is visible, so
/shipand plan reports cannot state what the host subagents spent ("six host subagents, spend unknown"). - A merge rule keyed on "ship receipt on the head" has no machine-checkable
form on the platform side: the controller greps the PR body.
gstack-ship-queue readyandtrain buildcheck it on the harness side.
Approvals
- An autoplan gate inside a crew thread costs a Captain round trip even when
the owner's standing answer is "take every recommendation"; record the
standing answer once with
gstack-approvalsand cite it. Rows mirror to the Captain drive'sapprovals/directory when the Captain created one, so other crew threads can read them; without it they stay in the private project-user Drive and the Captain carries the text into PR bodies.
Harness gaps the same files name (fixed or owned in gstack, listed so the
reader knows the date): the pregate failing every touched file in a
repository without .gstack/pregate.json; /ship printing no
GSTACK_RESULT: skill=ship line in unattended mode; the receipt going stale
on a late push (now refused by ready); the receipt-write step truncating a
PR body; /ship's docs audit blocking on a risk the owner must accept by
hand; the pregate's secret scan refusing benign per-trial dummy tokens with no
allowlist; no cost ceiling surfaced at autoplan gates.
| What | Path |
|---|---|
| The user-scope skill and the Captain guide | capy/skill/gstack/SKILL.md, capy/skill/gstack/captain.md, capy/skill/gstack/scripts/install.sh |
| Captain templates and the Captain's day | captain/templates/, docs/captain.md (ship with the /captain skill) |
| Install on Capy, snapshots, the launch line | docs/capy-install.md |
| Ship policy, queue and trains | docs/ship-policy.md, lib/ship-queue*.ts, bin/gstack-ship-queue, bin/gstack-restamp |
| Pregate and lanes | docs/pregate.md, bin/gstack-pregate |
| Flaky reruns and records | docs/TESTING_INTERNALS.md#flaky-reruns, scripts/lib/paid-rerun.ts, scripts/lib/ci-history.ts |
| Weekly release | docs/releases.md, scripts/release-cut.ts, .github/workflows/weekly-release.yml |
| Scorecard | bin/gstack-factory-scorecard, lib/factory-scorecard.ts, retro/SKILL.md.tmpl Step 7.5, test/factory-scorecard.test.ts |