fix: isolate worktree pools per operational home - #2804
Conversation
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Reviews (3): Last reviewed commit: "no-mistakes(document): Document Git-prov..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
Speaking as Kun's firstmate: VISION: mixed. Per-home pool isolation serves peace of mind (two homes must not share a Treehouse pool). Fail-closed custody and authenticated pool config align with scripts stopping safely. It misses "the first mate reads projects but does not change them": Treehouse-backed dispatch writes Class: default-behavior. Security: not a product exploit in the review, but Greptile P1s (mutable Overlap / HOLD: edits CI: HEAD Workflows approved: no (nothing action_required / no runs on HEAD). Land-eligible: NO. Waiting on the author to rebase onto main and isolate the pool work, not on the captain. Captain-flag NOW: no. |
Treehouse keys a worktree pool by the repository plus the clone's directory name, not by the checkout, and firstmate clones every project to $FM_HOME/projects/<name>. Two homes therefore drew from ONE pool while neither could see the other's task records, so the pool re-leased a slot that the other home's task still named and whichever task was cleaned up first hard-reset the copy the other was working in. Four pieces close that, each the smallest thing that removes the class and none of them a control layer over treehouse: - bin/fm-pool-root.sh gives each home its own pool root through the one knob treehouse's config exposes, and bin/fm-spawn.sh claims it before asking for a slot. It is idempotent, preserves other keys, keeps the file out of the clone's status, and refuses a tracked treehouse.toml rather than rewriting project content. - bin/fm-spawn.sh refuses an acquired copy that another task in this home already claims, after the slot is acquired and before the base refresh touches it. The refusal deliberately returns nothing: `treehouse return` terminates processes and hard-resets the copy, which is the damage being prevented. - bin/fm-teardown.sh asks a project's own `check:worktree-custody` script, when it published one, after the landed-work verdict and before anything destructive, and refuses on its exit 1. - bin/fm-spawn.sh asks a project's own `pool:release-delivered` script, when it published one, before leasing, so a pool exhausted by delivered copies nobody handed back stops blocking dispatch. That one is capacity rather than safety, so a failure warns and the spawn continues. Existing leases are untouched: a worktree already handed out keeps its path and is still returned normally after its clone is re-rooted, so shared pools drain on their own and only new leases separate. bin/fm-project-script-lib.sh is the single owner of the "a project opts in by publishing a script" contract both callers use.
327e106 to
6baafc2
Compare
Summary
Validation
Accepted follow-up
|
|
Speaking as Kun's firstmate: Re-inspect after the 3:10pm PT 8/22 pass (then HEAD VISION (read current main 1231b6a in full). Inspected Class: default-behavior. NEVER auto-eligible. Security: flag. Greptile P1s still on the thread (mutable Overlap / HOLD: still edits CI / NM: no structured Workflows approved this pass (diff review, no workflow-file risk): 32610308908 (Require no-mistakes), 32610308915 (CI). Land-eligible: NO. Waiting on the author to isolate the pool work, attach a matching attestation, and get green CI+NM — not on a rebase from this box, and not on the captain. Captain-flag NOW: no. |
2 participants
Summary
Validation