# ask-gpt trusted attachment staging

audience: AI coding agents first.

- Status: IDLE — parked by owner 2026-08-15; not abandoned, resume when the delivery program is done.
- Outcome: jailed `ask-gpt -a <file>` stages attachments into trusted runtime before `systemd-run`, preserves bytes and argument order, removes staged files, and reports concrete failures.
- Source request: static-dispatch generation must continue through validation, tests, install, land, deploy. Repeated fresh and reseeded sends fail during attachment.
- Acceptance: focused launcher tests cover one/multiple attachments, `-a`/`--attach`, missing input, cleanup, failed relaunch, spaces, and `GPTBRIDGE_STATE_DIR`; installed jailed attachment canary reaches a fresh conversation without `--resume`.
- Preserved WIP: scheduler package SHA-256 `ec4b2ff5053b5f220aec086445e7db49e50d35129e34d74f522c701ab17e78f6`; no generated artifact exists.
- Constraints: NEVER resume ask-gpt this session. NEVER mutate shared checkout. Install before landing. Restrictive staging permissions. No secret or unrelated file staging.

## Execution

1. Add fail-closed attachment staging and cleanup in `modules/gptbridge/trusted_launcher.py`.
2. Add deterministic focused tests.
3. Run focused gptbridge gates cleanly.
4. Install through project deploy path; invoke real jailed attachment canary.
5. Commit, land, deploy landed source.
6. Start fresh static-dispatch ask-gpt generation; validate and ship result.

## Current receipt

2026-08-12: four fresh static-dispatch attempts failed; latest reseeded attempt still failed `phase: attaching`. Read-only diagnosis proved jailed cache path is passed unchanged across `systemd-run`; escaped launcher cannot read it.

## Next executable action

Implement staging + tests in isolated repair worktree.

Parked IDLE by owner 2026-08-15 — not abandoned; resume when the delivery program is done.