trunk-merge/pr-1217/9c98722b-9d56-4520-8d5b-18882e03bd8d - #1226
Closed
trunk-io[bot] wants to merge 9 commits into
Closed
trunk-merge/pr-1217/9c98722b-9d56-4520-8d5b-18882e03bd8d#1226trunk-io[bot] wants to merge 9 commits into
trunk-io[bot] wants to merge 9 commits into
Conversation
…3756) Family 5 of the managed-boundary leak: the private repo's former proper name and live paths inside it, left behind when families 1-4 were scrubbed. The census that drove the earlier passes scoped itself to docs/ + AGENTS.md, so code and config were structurally invisible to it. Sweeping the tracked tree instead found the former name in apps/eng-docs and .moon/workspace.yml, and family 4 still alive in 11 files under tools/ and agent-image/. Records keep every technical claim; only the provenance descriptor changes. A path citation becomes the mechanism it establishes, so a reader with access can still find the source and a reader without one learns the design. The replacement vocabulary (prior art, out of tree, the fleet, managed-plane) all pre-existed in the corpus. The gate now scans for the former name too, but cannot do it whole-word: the word is ordinary English throughout go/ (a sealed sum type, a ciphertext sealed under a key, an egress-sealed agent). Measured over the tracked tree a whole-word scan flags 60 lines, every one legitimate -- a gate that is 100% false positives gets switched off. It matches only repo-shaped uses: a path inside the repo, its docsite host, its possessive, or the word followed by a repo noun. Tests pin both directions, including the three public names that carry the string and must never trip it. Code comments lose their migration narration outright rather than being reworded -- a public reader needs what the code does, not where it came from. Co-authored-by: Matt Wilkinson <matt@rigel.build> wip: resolve rebase conflicts
…774) DL-241 recorded ten tools and enumerated ten; createForgeTools ships twelve. The transition pair (forge_transition_issue_state, forge_transition_pull_request_state) arrived with DL-342 / RIG-3331 and the row was never refreshed. The row's own closing line makes the count load-bearing for future toolset-refresh rows, so a refresh diffing against 'ten' would start from a wrong base. Amended in place per Matt. Also retires the row's ratified subscribe caveat: both arms persist now (EnsureAgentForgeSubscription / DeleteAgentForgeSubscription), so they are no longer CodeUnimplemented stubs. The stale caveat was also shipping to agents at runtime. SUBSCRIBE_RULE told every model the subscribe calls 'return unimplemented' and 'should not be relied on yet', steering agents off a working feature; it now describes what a subscription does. Record tasks T1/T2 are checked, its counts and the ForgeCallRequest arm range (2-11 plus 14-15) corrected. Co-authored-by: Matt Wilkinson <matt@rigel.build>
…IG-3774) Review on #1209 caught the miss: forge.ts's own header still said 'ten native tools' and 'TWO SUBSCRIPTION TOOLS SHIP DORMANT ... CodeUnimplemented stubs', contradicting the SUBSCRIBE_RULE rewritten four hundred lines below it in the same file. My post-edit grep searched my own phrasings, so it could not see the original wording. Swept every remaining site: - forge.ts header: twelve tools; the subscription arms described as live. - packages/compass-agent/AGENTS.md: the package contract forge.ts names as authoritative. Ten -> twelve, both transition tools added under writes (approval: "write", verified in forge.ts), and the 'unimplemented until the writer lands' sentence retired. - compassv1.ts barrel comment: ten -> twelve forge arms. - The prescriptive createForgeTools docstring in the design record's T2 block. Left deliberately: one 'ten precise JSON Schemas' in a rejected alternative (a historical argument about a multiplexed tool, not a claim about what shipped), and the gitignored eng-docs ledger copy, which regenerates. Co-authored-by: Matt Wilkinson <matt@rigel.build>
…s (RIG-3783) Every test in cli.config-passthrough.test.ts does real filesystem work (mkdir + writeFile fixtures, then a buildFleetSettings/main read over both config layers). Under the parallel pre-push gate that I/O outruns bun's implicit 5s per-test default and flakes — measured 5423ms on the fleet-overlay test. This is the same starvation RIG-3609 fixed for the afterEach; the buildFleetSettings block and its ~19 siblings never got the same treatment. A file-wide setDefaultTimeout(60_000) covers the whole class in one line; the (g) probes keep their explicit 130_000 (an explicit per-test timeout still overrides the default). No production behavior change.
…756) Review findings on PR #1216, both mediums on the gate rather than the scrub. The narrow pattern set missed two citation shapes, and both are shapes this scrub removed BY HAND — so the standing backstop would not have caught its own regression: - the space form, `sealed apps/docs/scripts/deploy.ts`, which is the most natural way to cite a file in another repo - the hyphenated repo-noun, `sealed-monorepo` / `sealed-repo` / `sealed-private` The space-form arm anchors on a source-file extension rather than on any slash-bearing token. A looser form false-positives on ordinary English, which carries slashes too: "values sealed and/or rotated" and "sealed in transit/at rest" both match a bare `sealed\s+\S*/`. Validated at 15/15 engineering-word negatives and 9/9 leak shapes; zero hits over the tracked tree. The module header contradicted the code after the two-name change, still reading "orion ONLY / a single blunt token beats a clever regex" while the former name is matched by exactly such a narrowing set. Rewritten to state both names and why the asymmetry is deliberate: blunt where the token is unambiguous, narrow where it collides with English. Also drops `\b` from the git grep pre-filter. It is a GNU extension, not base POSIX ERE, and a toolchain change that made git treat it literally would match nothing and exit 1 — a legitimately-clean signal — so the gate would fail OPEN. The pre-filter only has to be a superset; lineHasToken owns the boundary. Verified superset: 174 unanchored vs 168 anchored lines. Tests 26 -> 29. Mutation-tested: removing the two arms turns 29 pass/0 fail into 26 pass/3 fail. Co-authored-by: Matt Wilkinson <matt@rigel.build>
…(RIG-3756) Review round 2 on PR #1216: high 0, medium 0, low 2. This closes the one low that was a real defect; the other is explicitly informational (the reviewer adjudicated the extension-anchor narrowing as correct and recommended no change). The docstring justified the extension anchor by naming `sealed\s+\S*\/`, then attributed two false positives to it. Only the first actually fails under that pattern: in "rows sealed in transit/at rest" the `\S*` stops at the space before "in", so no slash is adjacent to the token run. Both examples fail under the DEPLOYED arm with its extension anchor stripped, which is the pattern the argument is really about — I had probed the deployed arm and then written up a different regex. A maintainer testing the cited one would find it does not hold and might conclude the anchor is unnecessary. Now names the anchor-stripped arm, and records the trade it buys: a directory-only citation and an off-list extension are missed, deliberately, because broadening to a bare `sealed <word>/<word>` puts those prose hits back and an all-false-positive gate gets switched off. Also makes the whole-word measurement exact. It read "flags 60 lines"; the count outside this gate's own carve-out is 59. A published number that drifts is worse than a stated magnitude, so it now gives the magnitude and scopes the exact figure to its measurement. Verified every claim the docstring now makes: both prose examples clean under the deployed arm, both documented misses confirmed, all three citation shapes still caught. Tests 29 pass / 0 fail; gate clean; root:ci rc=0. Co-authored-by: Matt Wilkinson <matt@rigel.build>
trunk-io
Bot
deleted the
trunk-merge/pr-1217/9c98722b-9d56-4520-8d5b-18882e03bd8d
branch
September 14, 2026 02:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request was created and is being managed by Trunk Merge.
This pull request is based on the main branch at SHA 81aff4d0e3b66616985b4d309bc081320e7860a1.
See more details about each PR in the batch here:
When CI completes, this pull request will be closed automatically.
Pull Requests Being Tested
This pull request is testing a batch with the changes from pull requests 1217, 1209, and 1216 - batching documentation.