-
Notifications
You must be signed in to change notification settings - Fork 0
FE-1320: Structural private-mission isolation for /compare-specs #415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: ln/fe-1318-canonical-document-reconciliation
Are you sure you want to change the base?
Changes from all commits
e92e655
547c7f3
2757f5a
54f0415
1a721c7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,8 @@ Use these repository-relative homes and no substitutes: | |
|
|
||
| A mission is ordinary-language Markdown for the top-level session playing the simulated user. It is not controller YAML, a Brunch seed, comparison-harness selection, or harness configuration. Never use `.fixtures/seeds/` as mission input. Never put the mission text, file, or path in a harness context or cwd. A harness receives only its approved minimal framing and the natural opening and later answers that the top-level session chooses from mission truth. | ||
|
|
||
| Every harness gets a fresh system-temporary external target root outside the controller checkout, scratch run tree, and retained run tree. Before launch, resolve the target and controller paths and verify that they are separate and that its ancestor directories contain no controller-private run material. Brunch still launches from the Brunch repository root and receives the external target through `--workspace`; generic harnesses launch with the external target as their cwd. This placement closes ordinary target-relative ancestor traversal, including the known `../../private-mission.md` path. It is not an OS sandbox and does not claim isolation from unrestricted absolute-path or whole-host discovery. | ||
|
|
||
| A saved mission is editable. An approved run is historical evidence: never overwrite an existing run directory, private mission snapshot, `harness-setup.md` snapshot, transcript, target output, or report. Later mission revisions affect future runs only. Historical setup snapshots keep their existing names and bytes; never rename them. Keep retained paths repository-relative; do not retain workstation-absolute paths. | ||
|
|
||
| All operator choices and approvals must work through ordinary typed text. If a structured question tool happens to exist, it may improve presentation, but correctness and progress must never depend on it. | ||
|
|
@@ -57,7 +59,7 @@ Run setup is intentionally small, run-specific, and never written into the reusa | |
| - **Brunch:** use built-in Specify mode, plus only the output instruction needed to identify the requested review-ready document and path. | ||
| - **Generic harnesses:** use a small instruction to conduct a question-led specification conversation and author the requested review-ready Markdown document. Do not preload mission facts or prescribe conclusions. | ||
| 3. Preflight only each selected harness's filesystem and adapter prerequisites, including the pinned `pi-interactive-shell` package and cleanup capability where applicable. Do not launch a synthetic conversation to test provider/model access. Report provider/model failure honestly if the real harness launch fails. Check Pi's adapter only when Pi is selected. | ||
| 4. Allocate a fresh isolated target cwd/session for each selected harness. This is the harness's comparison target, not necessarily the controller process cwd: Brunch's controller must launch from the Brunch repository root and address the fresh target through `--workspace <fresh-target-cwd>`, while a generic harness's structured spawn uses the fresh target cwd as its process cwd. The top-level session remains the shared simulated-user actor, so disclose harness order and shared actor context; do not claim fresh-per-harness actor isolation or equivalence to a rigorous campaign. | ||
| 4. Allocate a separate fresh system-temporary external target root for each selected harness using the host's standard temporary-directory facility. Resolve its canonical path and fail setup unless it is outside the controller checkout, scratch run tree, and retained run tree and its ancestor directories contain no `private-mission.md`, `harness-setup.md`, or other controller-private run material. This is the harness's comparison target, not necessarily the controller process cwd: Brunch's controller must launch from the Brunch repository root and address the external target through `--workspace <fresh-target-cwd>`, while a generic harness's structured spawn uses the external target as its process cwd. The top-level session remains the shared simulated-user actor, so disclose harness order and shared actor context; do not claim fresh-per-harness actor isolation or equivalence to a rigorous campaign. | ||
| 5. Display together: the complete private mission; selected harnesses and order; exact per-harness target-visible framing; mission id; collision-safe run id; requested target document path; scratch and retained paths; and each adapter. Clearly label the mission **top-level-session-only** and the framing **harness-visible**. | ||
| 6. Ask through ordinary text for explicit **approve**, **revise**, or **reject**. Revise and redisplay the complete setup, or reject and stop; do not launch partially. | ||
|
|
||
|
|
@@ -91,8 +93,8 @@ Run selected harnesses sequentially. For each harness: | |
|
|
||
| Generic harnesses author the requested Markdown file themselves in their cwd. An unavailable or mismatched adapter makes the harness failed; never substitute, silently drop it, or reconstruct output. | ||
| 6. Retain the exact harness-visible initial framing and transcript, including every user answer and decision. This is the disclosure record: any mission fact visible to the harness must have arrived through a natural opening or subsequent answer. | ||
| 7. Acquire the harness-authored document if it exists. Never author, reconstruct, complete, rewrite, or improve it. Missing or partial output remains missing or partial. | ||
| 8. On every outcome, retain state, harness-visible interaction, target-cwd/session identity, final process status, document that exists, and cleanup notes. Kill remaining processes, dismiss the completed shell record, and verify no comparison-harness shell or process remains before starting another. | ||
| 7. Locate the harness-authored document if it exists without altering it. Never author, reconstruct, complete, rewrite, or improve it. Missing or partial output remains missing or partial. | ||
| 8. On every outcome, kill remaining processes and verify no comparison-harness shell or process remains. Before dismissing the completed shell record, save its exact harness-visible transcript from the controller-owned `interactive_shell` record into controller-owned scratch evidence. Copy only any unchanged harness-authored document from the external target into that scratch evidence; retain target-cwd/session identity, final process status, and cleanup notes. Then dismiss the shell record, remove that harness's external target root, and verify it is gone before starting another harness. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Retention conflicts with absolute targetsMedium Severity The procedure now requires retaining Additional Locations (1)Reviewed by Cursor Bugbot for commit 1a721c7. Configure here. |
||
|
|
||
| Do not notify completion while any harness is ready, running, or waiting. After every selected harness is finished or failed, give one aggregate notification. Review scratch assembly, then deliberately copy it to the unused immutable run identity without changing `provenance.json`, snapshots, transcripts, or harness-authored documents. | ||
|
|
||
|
|
||


There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approval omits external target paths
Medium Severity
Step 4 now allocates per-harness system-temporary external target roots, but step 5 still only displays scratch and retained paths. Operators approve the isolation-critical placement without seeing those target roots, so a skipped or in-tree allocation can pass review unnoticed.
Additional Locations (1)
.pi/prompts/compare-specs.md#L61-L62Reviewed by Cursor Bugbot for commit 1a721c7. Configure here.