Garry Tanandcapy-ai[bot]
6417abf7a6
* Load the Capy crew skills only on Capy machines (GST-1833) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Add changelog entry for Capy-only crew skills (GST-1833) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Move the Capy-only crew tooling into crew/ and run its tests only when needed (GST-1833) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Test that the Capy launch file puts crew/bin on PATH Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Count any ~/.capy as a Capy machine, so a Mac running Capy keeps /captain Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Fix the tests and fixtures that broke when crew tooling moved into crew/ Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Plan every crew test when a pull request's merge-base can't be read Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Add a test that checks each crew-only module left the root tree for crew/ Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Run crew tests on pull requests that change bin/ commands or workflows they drive Review-Finding: p1/specialist-batched#1 reader=testing Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Keep running every crew test on every pull request; the skip comes in a later change Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Keep copied installs and older release bisects working after the crew/ move Setup now copies crew/lib into every host's runtime root beside bin and lib, so Windows installs (which copy instead of linking) can still start gstack-ship-receipt, gstack-pregate and the other commands that import it. The release bisect runs the train-gate script from wherever the checked-out commit has it, so a bisect over commits from before the move still gets a verdict. Review-Finding: p1/outside-voice#1 reader=outside-voice Review-Finding: p1/outside-voice#2 reader=outside-voice Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Say in the changelog that Windows installs keep working after the crew/ move Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Point the harness guide's merge-queue rows at crew/lib/ where those modules moved Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Point the plain-title test at the wave module's new home in crew/ (GST-1833) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --------- Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
gstack on Capy
This folder holds the parts of gstack that only Capy crews use: the tools that
run a crew of coding agents under a Captain. It stays in the public repo, but
./setup loads it only on a Capy machine. Anywhere else, setup skips it and
gstack works exactly as it does without it.
What Capy users get on top of gstack
- Captains.
/captainruns many agent threads from one controller: lanes send a READY block and never merge, the controller keeps the digest, relays approvals in a fixed shape and runs a daily flaky-test pass (docs/captain.md). - A merge queue.
gstack-ship-queuelands verified pull requests alone or in trains, checks the exact head before it merges, and stamps the version only at release time. - Receipts.
/shipleaves a receipt for the head it checked, so the controller can tell that a pull request was reviewed and tested at the commit it merges. - Budgets.
/shipand/autoplanmeter their own spend against the cap a brief sets, and stop or hand off before they cross it (docs/ship-budget.md).
How the whole factory fits together: capy/README.md.
How it is loaded
A Capy machine is one where CAPY_MACHINE_CONFIG is set (cloud machines) or
~/.capy exists (cloud machines and paired devices, such as a Mac running
Capy). Any ~/.capy counts, so when it is unclear the crew skills install
rather than a Capy user losing /captain. gstack_on_capy in
bin/gstack-install-registry.sh is that test, and
GSTACK_CREW_SKILLS there lists the crew skills. On a Capy machine setup and
gstack-relink register them like any other skill; elsewhere they get no entry
on any host, and an entry an earlier install made is removed.
On Capy the session launch file (bin/gstack-capy-install) also puts
crew/bin/ on PATH, so the crew commands keep their bare names there. Public
CI runs crew/test/ with the rest of the free suite.
What is here
| Path | What it holds |
|---|---|
bin/ |
gstack-release-gate (the paid gate on main every 8 hours) and gstack-coauthor-trailers (credit for ported contributor work) |
lib/ |
merge trains and waves (ship-queue-train*, ship-queue-wave, the land lock, screens, rechecks), the release gate, version-gate trains and lane ownership |
scripts/ |
the release cut and its daily check (release-cut, release-cadence), and the paid-eval CI steps only our crews run (train gate and backstop, gate cost, gate reuse, receipt recovery, census arms, judge calibration configs) |
test/ |
their tests |
docs/ |
the manuals: running a Captain crew and the recommended harness |
The crew tooling moves here in stages. Code that no public skill calls comes
first; the steps /ship, /review and /autoplan take only for crews move
after they call it through one switch. Some crew tools stay outside crew/ for
now because public code still calls them: /captain's own folder (the skill
generator reads top-level folders), gstack-ship-queue, receipts, the
pre-gate, spend caps and approvals.