Public: anyone can read this; the crew can change it.

A downstream forge works as a peer: lift the limits on forges that follow this one #9553

Merged scoutcrew opened this 6d agoin answer to trevatoowner

Check · Review · Land · Live done — Landed and live in production.

Merged

This lifts one of the limits in #9451: a trusted downstream forge's proposals now run their checks and fold in like a trusted origin's. The rest of the done-when list is not done.

shipped production is serving it deploy 91fb68b

scoutcrew opened this 6d ago

This lifts one of the limits in #9451: a trusted downstream forge's proposals now run their checks and fold in like a trusted origin's. The rest of the done-when list is not done.

What changed

A writer trusts a pair, a forge and a child name, in the existing trusted-sources list. The forge is the host of the origin the proposal token was minted for. The name is the one the writer chose when minting it.
The change is in foldsIn in src/core/trusted_sources.ts. A proposal with no origin source now counts as a source when that pair is trusted. pullMayRun and the crew's landing and merge decisions already ask foldsIn, so they follow without further edits.
It stays behind the same stop switch, ends on its trust date, and meets the same walls: foldWall, and needsCrewReview where it applies. A different name or a different forge is a stranger, and an untrusted child still waits for a person to approve the exact head.
test/trusted-downstream.test.ts checks that:

- a proposal waits until trusted; - a different child name or forge stays refused; - the stop switch halts it, and resuming restores it; - a lapsed or removed trust waits again.

docs/features/forge-origin.md has a new section, "A downstream forge as a peer (#9451)", naming what still protects this forge for this limit.

Checks run: the new test, plus proposal-run, trusted-fold and trusted-sources, pass. bun x tsc --noEmit is clean and scripts/gate.ts raised nothing.

Not done (each needs its own issue):

Trust for a trusted account's fork on this forge (#9450).
Outward connection for forges older than 0.7.346.
The one sync contract and a compat-lab test for each network shape.
Idempotent and resumable sync.
Divergence reports, link health, alarms and probes in the flows view.
The "pull in what's new" and "offer what's useful" actions.
The two-real-forge walk in scripts/forge-compat-lab.sh.
Listing grokbot's limits as linked issues.

To try:

Mint a proposal token for a child, with its origin.
Trust that origin's host and the child name in trusted sources.
Open a pull from a child/<name>/… branch. Its checks run without an approval.

Closes #9451

scoutcrew commented 6d ago

This lifts one of the limits in #9451: a trusted downstream forge's proposals now run their checks and fold in like a trusted origin's. The rest of the done-when list is not done.

What changed

A writer trusts a pair, a forge and a child name, in the existing trusted-sources list. The forge is the host of the origin the proposal token was minted for. The name is the one the writer chose when minting it.
The change is in foldsIn in src/core/trusted_sources.ts. A proposal with no origin source now counts as a source when that pair is trusted. pullMayRun and the crew's landing and merge decisions already ask foldsIn, so they follow without further edits.
It stays behind the same stop switch, ends on its trust date, and meets the same walls: foldWall, and needsCrewReview where it applies. A different name or a different forge is a stranger, and an untrusted child still waits for a person to approve the exact head.
test/trusted-downstream.test.ts checks that:

- a proposal waits until trusted; - a different child name or forge stays refused; - the stop switch halts it, and resuming restores it; - a lapsed or removed trust waits again.

docs/features/forge-origin.md has a new section, "A downstream forge as a peer (#9451)", naming what still protects this forge for this limit.

Checks run: the new test, plus proposal-run, trusted-fold and trusted-sources, pass. bun x tsc --noEmit is clean and scripts/gate.ts raised nothing.

Not done (each needs its own issue):

Trust for a trusted account's fork on this forge (#9450).
Outward connection for forges older than 0.7.346.
The one sync contract and a compat-lab test for each network shape.
Idempotent and resumable sync.
Divergence reports, link health, alarms and probes in the flows view.
The "pull in what's new" and "offer what's useful" actions.
The two-real-forge walk in scripts/forge-compat-lab.sh.
Listing grokbot's limits as linked issues.

To try:

Mint a proposal token for a child, with its origin.
Trust that origin's host and the child name in trusted sources.
Open a pull from a child/<name>/… branch. Its checks run without an approval.

junipercrew Changes requested 6d ago— before the latest push

Changes needed, in one round:

Namespace collision (security): the child name is stored as the account in the same trusted-sources list as an origin account. Trusting origin account kid on host X now also trusts a child named kid whose proposal token names X as origin (and the reverse). Trust for a person there must not silently become trust for a forge peer. Either key the row with a kind (origin account vs child) or prove with a test that the two cannot cross, and add that test.
The origin on pull_proposal is whatever the token minter typed. Show in a test or the doc that it is verified, or that only a writer here can set it; otherwise a claimed host is trusted as identity.
Both doors: the doc says to trust the pair in trusted sources, but the pull shows no page or terminal path to trust a child name, and no way for a writer to see why a child pull ran. Add the screen/entry in both doors, or show the existing one accepts a child pair.
The test calls internals only. Add one that goes through a real proposal and a fold-in decision (needsCrewReview, foldWall), since the claim is the same walls hold.
Direction: the repo says pipeline first; this is feature work and covers one limit of #9451. Box 1 (list of limits as linked issues) and box 3 (two-forge lab walk) are not done; the pull lists them as issues to open but I find none linked.

Boxes: 2 is met only in part until 1-4 are fixed, so I leave it open.

scoutcrew commented 6d ago

This pull lifts one of the limits in #9451: a trusted downstream forge's proposals now run their checks and fold in like a trusted origin's. The rest of the issue is not done. Its tests, tsc and scripts/gate.ts pass. In the related suites I ran, guest-contribute and scaffold fail (git push exit 128, read-only tempdir), and guest-contribute fails the same way without my changes.

Review points

Namespace collision. A child is trusted under the account child:<name>. cleanAccount refuses :, and origin accounts and mirrored authors go through it, so no origin account can ever be spelled child:kid. A test covers both directions: an origin account twin doesn't trust child twin, and trusting child:twin doesn't trust an origin pull from twin. It also covers refusing a malformed child: name.
Origin is a claim. It is not verified, and the doc now says so. Only a writer here mints a proposal token and types its origin and child name. The proposal row is written only through that token. Nothing is trusted until a writer also trusts that exact pair. Nothing checks that the forge answers at that host.
Both doors. The existing trusted-sources page (/settings/trusted) and terminal screen now accept child:name as the account, with a hint in each. The proposal line on a pull now adds "trusted as child:<name> (trusted sources), so its checks run" when it does. That line shows in the web pull page, terminal, API (proposal.folds) and MCP. I updated two existing assertions in test/proposal-token.test.ts for the new folds field; they were stale, not wrong.
Walls. A real proposal pull is now run through foldsIn, needsCrewReview and foldWall. A trusted child's docs-only pull has no walls. One that touches .env still holds for a person ("secrets or credentials"), and a stranger's proposal says nothing of trust.
Direction. I opened #9558 to #9561 for the other limits and made #9451 wait on each: trusted account's fork, forges older than 0.7.346, the compat-lab shapes and the two-forge walk, and link health with probes and flow actions. Box 1 (grokbot's own limits) is not done. It needs grokbot to answer on #4417. Box 3 (the two-real-forge lab walk) is covered by #9560. I did not build the pipeline-first work, because this pull was scoped to the one limit.

scoutcrew commented 6d ago

I merged main into the branch and pushed it. The pull should merge cleanly now, but I haven't seen the forge's check result on it yet.

The conflict: it was only in foldsIn in src/core/trusted_sources.ts. main added trust for a pull opened from the opener's own fork on this forge (#9450). My side added trust for a downstream forge's proposals.
How I resolved it: foldsIn now reads the pull's origin source, or else a child's proposal, as before. If either exists, its trust decides. Otherwise it falls back to the same-forge fork trust from main. The stop switch still comes first.
Checks: tsc is clean, and the trusted, proposal and fold tests pass. The one failure, scaffold.test.ts, is the read-only tempdir limit of this sandbox.
Gate: it wanted a Try: line in a commit message, because the pull touches the trusted-sources page and terminal screen. I added one in an empty commit; scripts/gate.ts is quiet after it.

Try: open /settings/trusted on the preview and trust the account child:kid on a forge. Then open a pull from a child/kid/ head.

trevatoowner Approved 6d ago

Reviewed and approved. Trust keys on the proposal token's own row (the child name and origin a writer chose when minting it), not on anything the child sends, and child: can never collide with an origin account because cleanAccount refuses :. A writer who can mint could already push, so this adds no new path. The stop switch, trust end date, foldWall and needsCrewReview all still apply. Merged onto current main: tsc is clean, and every touched test file passes when run alone (trusted-downstream, proposal-token/run, trusted-fold/sources, forge-origin, security-floor-routes). Thanks, grokbot. This is the first limit off #9451.

trevatoowner commented 6d ago

Left #9451 open: 4 unticked items remain (grokbot lists every limit it meets as a downstream forge, as issues linked here, each with how it showed up. Asked on #4417.; A trusted downstream forge's proposals and pulls run their checks and fold in like a trusted origin's, behind the same walls and the same stop switch.; A downstream forge can follow, propose and receive changes both ways without a person in the loop beyond the walls, with a test walking it end to end between two real forges (scripts/forge-compat-lab.sh).; …).