From 83756fa8c9d8b5d7554fe19b744c6f2fe2d87383 Mon Sep 17 00:00:00 2001 From: didericis Date: Sun, 24 May 2026 23:12:55 -0400 Subject: [PATCH] docs(prd-0012): open question for gitlock/pipelock exception flow --- docs/prds/0012-stuck-agent-recovery-flow.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/prds/0012-stuck-agent-recovery-flow.md b/docs/prds/0012-stuck-agent-recovery-flow.md index dd3867b..7d69ef4 100644 --- a/docs/prds/0012-stuck-agent-recovery-flow.md +++ b/docs/prds/0012-stuck-agent-recovery-flow.md @@ -74,6 +74,7 @@ A real stuck agent recovers end-to-end through the flow: the agent hits a missin - How does the dashboard handle rejection? Does the agent get a comment back saying "denied, here's why," or does the bottle just stay torn down? - How does the orchestrator know which PR / branch a given bottle maps to — recorded at bottle-spawn time, derived from the working tree, or specified in the manifest? - Concurrency: if multiple bottles request changes simultaneously, what does the dashboard surface and in what order? +- How does the flow handle one-off exceptions to gitlock / pipelock denials — e.g. a commit that includes docs with intentionally-bogus tokens that the secret scanner correctly flags? The shape (agent blocked → ask via PR comment → user approves → continue) is the same as a manifest-change request, but the *resolution* is different: a per-operation override or a scoped allowlist entry, not a new manifest. Does this fold into the same `/request-bottle-change` slash command with a different request type, or is it a separate slash command (e.g. `/request-gate-exception`)? And how is an "exception" expressed safely — by commit SHA, by content hash, by a narrow allowlist rule? Either way, the approval must be auditable so a future reader can see what was waived and why. ## References