devcontainer: refresh for the plugin era — per-container claude state, worktree plugin wiring, parallel-safe compose naming #61

Author

Owner

{
  "status": "resolved",
  "chosen_option": "confirmed",
  "rationale": "Container runtime access is now verified by doing, not asserted. Root cause of the original gap was misdiagnosed at first and is worth recording: the operator's initial 'usermod -aG docker jochem' was run on a DIFFERENT MACHINE (Jochems-Forge) from the one this feature targets (jochems-server, which holds the repo, the worktree, the executing plugin and this session). The tell was that 'getent group docker' returned 'docker:x:973:jochem' in the operator's shell and 'docker:x:983:' here - a different GID, not a stale copy of the same group, which rules out a sandbox artifact and means two hosts. Re-running usermod on jochems-server gives 'docker:x:983:jochem', and 'sg docker -c docker version' now returns server 29.7.2 passwordlessly. INVOCATION MODE decided, which the precondition explicitly asked for and not merely 'access exists': docker-group membership on jochems-server, NOT sudo and NOT rootless. Rationale - the operator already holds sudo on this single-user box, so group membership grants no privilege they lacked; sudo-per-command was rejected because an unattended run cannot answer a password prompt, which would defeat the feature's purpose; rootless Docker is the stronger isolation story and would be the choice on a shared host, but its main benefit (a container escape lands as uid 1000 rather than root) is second-order here because the design never mounts the Docker socket into the container. Note for the build: a process acquires supplementary groups only at start, so THIS session must still wrap docker calls in 'sg docker -c'; dw.sh gets the group ambiently after the operator's next fresh login. Authority: operator performed the change and directed resolution as recommended, 2026-08-25.",
  "rejected_alternative": "Rootless Docker, and sudo-per-command. Rootless was turned down on cost-versus-benefit rather than merit - it is new infrastructure to install and maintain, and the escape-containment benefit it adds is redundant with the design's own boundary (no socket is ever mounted into the container). Sudo-per-command was turned down on a hard functional ground rather than taste: an unattended container start cannot satisfy a password prompt, so it would break the single use case the feature exists for, and a NOPASSWD rule to work around that would grant broader standing privilege than the group does."
}

```json { "status": "resolved", "chosen_option": "confirmed", "rationale": "Container runtime access is now verified by doing, not asserted. Root cause of the original gap was misdiagnosed at first and is worth recording: the operator's initial 'usermod -aG docker jochem' was run on a DIFFERENT MACHINE (Jochems-Forge) from the one this feature targets (jochems-server, which holds the repo, the worktree, the executing plugin and this session). The tell was that 'getent group docker' returned 'docker:x:973:jochem' in the operator's shell and 'docker:x:983:' here - a different GID, not a stale copy of the same group, which rules out a sandbox artifact and means two hosts. Re-running usermod on jochems-server gives 'docker:x:983:jochem', and 'sg docker -c docker version' now returns server 29.7.2 passwordlessly. INVOCATION MODE decided, which the precondition explicitly asked for and not merely 'access exists': docker-group membership on jochems-server, NOT sudo and NOT rootless. Rationale - the operator already holds sudo on this single-user box, so group membership grants no privilege they lacked; sudo-per-command was rejected because an unattended run cannot answer a password prompt, which would defeat the feature's purpose; rootless Docker is the stronger isolation story and would be the choice on a shared host, but its main benefit (a container escape lands as uid 1000 rather than root) is second-order here because the design never mounts the Docker socket into the container. Note for the build: a process acquires supplementary groups only at start, so THIS session must still wrap docker calls in 'sg docker -c'; dw.sh gets the group ambiently after the operator's next fresh login. Authority: operator performed the change and directed resolution as recommended, 2026-08-25.", "rejected_alternative": "Rootless Docker, and sudo-per-command. Rootless was turned down on cost-versus-benefit rather than merit - it is new infrastructure to install and maintain, and the escape-containment benefit it adds is redundant with the design's own boundary (no socket is ever mounted into the container). Sudo-per-command was turned down on a hard functional ground rather than taste: an unattended container start cannot satisfy a password prompt, so it would break the single use case the feature exists for, and a NOPASSWD rule to work around that would grant broader standing privilege than the group does." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "confirmed",
  "rationale": "Both halves of this gate are now configured and verified on the forge. Branch protection: 'tea branches --repo jbr870/devwork-skills' previously reported main with PROTECTED=false - the mechanism chosen at requirements time to close the container's remote-write reach simply did not exist, so AC-7 could not have passed. It now reports main PROTECTED=true with USER-CAN-PUSH=true. Both halves of that reading matter: protection blocks force-push and deletion (what the isolation decision was actually for), while push stays enabled so /dev:integrate's fast-forward merge to main still works - this project declares uat.open_pr false and merges directly, so a 'require pull request' configuration would have broken its own pipeline. The operator enabled push WITHOUT a whitelist, which is the better shape here: an empty whitelist with push enabled permits normal pushes for anyone holding write access while still refusing history rewrites, whereas a whitelist would be narrower than a single-user repo needs and would add ongoing maintenance. Token scope: a separate least-privilege token (issue/comment write, read repository, no repo-admin) is to be the one copied into containers, closing the API-bypass the security review identified - an admin-scoped token would let a permission-relaxed session disable the protection through the API and then force-push, making the protection decorative. RESIDUAL, recorded rather than hidden: with push enabled, a container can still APPEND commits to main; it cannot rewrite or delete history. That is consistent with the decision actually taken (force-push and deletion were the named threats) but it is not the same as 'a container cannot touch main'. Sibling feature/* refs remain rewritable and are carried separately as finding F-PO-61-2-8. Authority: operator configured the forge and directed resolution as recommended, 2026-08-25.",
  "rejected_alternative": "Requiring pull requests on main, and using a push whitelist. Require-PR was rejected because /dev:integrate fast-forward-merges directly to main on this project (uat.open_pr: false), so it would have broken the pipeline it was meant to protect - and the operator's first configuration attempt did exactly that, leaving USER-CAN-PUSH=false until corrected. A push whitelist was considered and dropped as narrower than a single-user repo requires, with no security gain over blocking force-push and deletion, at the cost of a list to keep current."
}

```json { "status": "resolved", "chosen_option": "confirmed", "rationale": "Both halves of this gate are now configured and verified on the forge. Branch protection: 'tea branches --repo jbr870/devwork-skills' previously reported main with PROTECTED=false - the mechanism chosen at requirements time to close the container's remote-write reach simply did not exist, so AC-7 could not have passed. It now reports main PROTECTED=true with USER-CAN-PUSH=true. Both halves of that reading matter: protection blocks force-push and deletion (what the isolation decision was actually for), while push stays enabled so /dev:integrate's fast-forward merge to main still works - this project declares uat.open_pr false and merges directly, so a 'require pull request' configuration would have broken its own pipeline. The operator enabled push WITHOUT a whitelist, which is the better shape here: an empty whitelist with push enabled permits normal pushes for anyone holding write access while still refusing history rewrites, whereas a whitelist would be narrower than a single-user repo needs and would add ongoing maintenance. Token scope: a separate least-privilege token (issue/comment write, read repository, no repo-admin) is to be the one copied into containers, closing the API-bypass the security review identified - an admin-scoped token would let a permission-relaxed session disable the protection through the API and then force-push, making the protection decorative. RESIDUAL, recorded rather than hidden: with push enabled, a container can still APPEND commits to main; it cannot rewrite or delete history. That is consistent with the decision actually taken (force-push and deletion were the named threats) but it is not the same as 'a container cannot touch main'. Sibling feature/* refs remain rewritable and are carried separately as finding F-PO-61-2-8. Authority: operator configured the forge and directed resolution as recommended, 2026-08-25.", "rejected_alternative": "Requiring pull requests on main, and using a push whitelist. Require-PR was rejected because /dev:integrate fast-forward-merges directly to main on this project (uat.open_pr: false), so it would have broken the pipeline it was meant to protect - and the operator's first configuration attempt did exactly that, leaving USER-CAN-PUSH=false until corrected. A push whitelist was considered and dropped as narrower than a single-user repo requires, with no security gain over blocking force-push and deletion, at the cost of a list to keep current." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "confirmed",
  "rationale": "Verified by executing the real operation, not by reasoning about it. A throwaway container (uid 1000, the host's SSH material mounted read-only, no other credentials) ran 'git ls-remote ssh://git@forge-devwork/jbr870/devwork-skills.git HEAD' and returned '2ceacfe8490eb7efb2258c1d62981eea06acb97b HEAD' at exit 0. That single call settles every unknown the precondition named, each of which could independently have broken push-only isolation: the forge-devwork host alias resolved from inside the container (so the SSH client configuration is being read, not just the key); the private key was readable and usable under the container's uid; host-key verification SUCCEEDED against git.wihslon.com without strict checking being disabled; and egress to port 2222 works from the container network. This is the path every route work takes out of a container depends on, so proving it was worth more than assuming it. SCOPE LIMIT, stated so the record is not read as broader than the evidence: the probe mounted the whole of ~/.ssh, whereas the SREQ narrows this to copying only the forge-devwork stanza, the key it names and the matching known_hosts entry. The risky properties above are proven; that the narrowed subset is sufficient is a build-time detail which AC-6 and selftest.sh assert. Authority: probe run by this session after D-PO-61-2-1 cleared, 2026-08-25.",
  "rejected_alternative": "Waiving it and letting /dev:develop discover any breakage. Turned down because the probe cost roughly two minutes once Docker access existed, and because a failure here would not surface as a clean error during the build - it would surface as an unattended run that cannot publish its work, which is the most expensive place to find it."
}

```json { "status": "resolved", "chosen_option": "confirmed", "rationale": "Verified by executing the real operation, not by reasoning about it. A throwaway container (uid 1000, the host's SSH material mounted read-only, no other credentials) ran 'git ls-remote ssh://git@forge-devwork/jbr870/devwork-skills.git HEAD' and returned '2ceacfe8490eb7efb2258c1d62981eea06acb97b HEAD' at exit 0. That single call settles every unknown the precondition named, each of which could independently have broken push-only isolation: the forge-devwork host alias resolved from inside the container (so the SSH client configuration is being read, not just the key); the private key was readable and usable under the container's uid; host-key verification SUCCEEDED against git.wihslon.com without strict checking being disabled; and egress to port 2222 works from the container network. This is the path every route work takes out of a container depends on, so proving it was worth more than assuming it. SCOPE LIMIT, stated so the record is not read as broader than the evidence: the probe mounted the whole of ~/.ssh, whereas the SREQ narrows this to copying only the forge-devwork stanza, the key it names and the matching known_hosts entry. The risky properties above are proven; that the narrowed subset is sufficient is a build-time detail which AC-6 and selftest.sh assert. Authority: probe run by this session after D-PO-61-2-1 cleared, 2026-08-25.", "rejected_alternative": "Waiving it and letting /dev:develop discover any breakage. Turned down because the probe cost roughly two minutes once Docker access existed, and because a failure here would not surface as a clean error during the build - it would surface as an unattended run that cannot publish its work, which is the most expensive place to find it." } ```

jbr870 commented

2026-08-25 13:50:10 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "confirmed",
  "rationale": "Verified by executing the real operation. A throwaway container with the host's tea binary and tea configuration mounted read-only ran 'tea login list' and then read issue #61 from the tracker: the login for the declared instance (wihslon / git.wihslon.com / jbr870) was present and usable, and the issue body came back over the network, at exit 0 with no interactive prompt. This confirms the SREQ's decision to change the token source. The route the existing container wiring used has never worked on this host and was not merely unproven: post-create.sh runs 'tea login add' with TEA_TOKEN read from a .env file that does not exist in this repository (only .env.example, with an empty value), and the failure is swallowed by '|| true'. So a container session has had no forge authentication at all since .devcontainer/ was authored - a second, independent reason (beyond the dangling plugin symlink) that it could never have completed a pipeline phase. Recorded as finding F-PO-61-2-11 and fixed within this slice. NOTE for the build: the probe validated the host tea config as the token source. Per D-PO-61-2-2 the token copied into containers should be the new least-privilege one rather than the operator's admin-capable host token, so the container's tea configuration must carry that token, not a verbatim copy of the host's. Authority: probe run by this session after D-PO-61-2-1 cleared, 2026-08-25.",
  "rejected_alternative": "Keeping the TEA_TOKEN/.env injection route and simply documenting that a .env must be created. Rejected because it preserves a design whose failure mode is silent - the existing '|| true' swallowed a credential-setup failure for the entire life of the current .devcontainer/, which is precisely how the breakage went unnoticed. Reading the token source that actually exists on the host removes the setup step rather than documenting it."
}

```json { "status": "resolved", "chosen_option": "confirmed", "rationale": "Verified by executing the real operation. A throwaway container with the host's tea binary and tea configuration mounted read-only ran 'tea login list' and then read issue #61 from the tracker: the login for the declared instance (wihslon / git.wihslon.com / jbr870) was present and usable, and the issue body came back over the network, at exit 0 with no interactive prompt. This confirms the SREQ's decision to change the token source. The route the existing container wiring used has never worked on this host and was not merely unproven: post-create.sh runs 'tea login add' with TEA_TOKEN read from a .env file that does not exist in this repository (only .env.example, with an empty value), and the failure is swallowed by '|| true'. So a container session has had no forge authentication at all since .devcontainer/ was authored - a second, independent reason (beyond the dangling plugin symlink) that it could never have completed a pipeline phase. Recorded as finding F-PO-61-2-11 and fixed within this slice. NOTE for the build: the probe validated the host tea config as the token source. Per D-PO-61-2-2 the token copied into containers should be the new least-privilege one rather than the operator's admin-capable host token, so the container's tea configuration must carry that token, not a verbatim copy of the host's. Authority: probe run by this session after D-PO-61-2-1 cleared, 2026-08-25.", "rejected_alternative": "Keeping the TEA_TOKEN/.env injection route and simply documenting that a .env must be created. Rejected because it preserves a design whose failure mode is silent - the existing '|| true' swallowed a credential-setup failure for the entire life of the current .devcontainer/, which is precisely how the breakage went unnoticed. Reading the token source that actually exists on the host removes the setup step rather than documenting it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted out of scope with NO follow-up issue, overriding this phase's defer-to-issue recommendation. The operator states the autonomous-run launcher will be covered by a different route than a sibling issue on this tracker. The gap itself is not disputed and is recorded on finding F-PO-61-2-1: #61 delivers the sandbox but not the thing that drives it unattended, so nothing in this feature demonstrates a full run completing inside a container - which is what the container was built for. What accept changes is only the bookkeeping: no sibling issue is spawned, so this finding plus this resolution on #61 are the entire durable trail. Flagged to the operator before posting so the choice was made knowing the trail ends here rather than in a backlog item. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding.",
  "rejected_alternative": "Spawning a sibling issue, which was this phase's recommendation and would have given the launcher work a tracked home with its own PREQ. Turned down by the operator in favour of covering it another way; not turned down on the merits of the gap, which stands as recorded."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted out of scope with NO follow-up issue, overriding this phase's defer-to-issue recommendation. The operator states the autonomous-run launcher will be covered by a different route than a sibling issue on this tracker. The gap itself is not disputed and is recorded on finding F-PO-61-2-1: #61 delivers the sandbox but not the thing that drives it unattended, so nothing in this feature demonstrates a full run completing inside a container - which is what the container was built for. What accept changes is only the bookkeeping: no sibling issue is spawned, so this finding plus this resolution on #61 are the entire durable trail. Flagged to the operator before posting so the choice was made knowing the trail ends here rather than in a backlog item. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding.", "rejected_alternative": "Spawning a sibling issue, which was this phase's recommendation and would have given the launcher work a tracked home with its own PREQ. Turned down by the operator in favour of covering it another way; not turned down on the merits of the gap, which stands as recorded." } ```

jbr870 commented

2026-08-25 13:50:10 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted with NO follow-up issue, overriding this phase's defer-to-issue recommendation. The operator will cover the sibling-branch question by another route. The exposure is real and stays on the record in finding F-PO-61-2-8 and in the SREQ's Technical Risks table: main is now protected against force-push and deletion, but every feature/* ref is unprotected, and each container holds the host's SSH keys - so one container can force-push over another container's branch and destroy its work. That is precisely the 'a mistake cannot reach the other runs' promise, and it is not yet fully met. It was not fixed inside this slice because the obvious fix (a blanket feature/* force-push rule) would collide with the rebase-then-force-push that /dev:integrate performs, so it needs a deliberate choice - protect selectively, change how integrate pushes, or accept the exposure - rather than a reflex. Current risk is low (single operator; a container only pushes its own branch) and rises when several unattended containers run concurrently, which is the feature's destination. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding.",
  "rejected_alternative": "Spawning a sibling issue to decide between selective protection, changing integrate's push strategy, and accepting the exposure. Turned down by the operator in favour of covering it another way. The narrower alternative of protecting feature/* immediately was already rejected at plan time because it would break /dev:integrate."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted with NO follow-up issue, overriding this phase's defer-to-issue recommendation. The operator will cover the sibling-branch question by another route. The exposure is real and stays on the record in finding F-PO-61-2-8 and in the SREQ's Technical Risks table: main is now protected against force-push and deletion, but every feature/* ref is unprotected, and each container holds the host's SSH keys - so one container can force-push over another container's branch and destroy its work. That is precisely the 'a mistake cannot reach the other runs' promise, and it is not yet fully met. It was not fixed inside this slice because the obvious fix (a blanket feature/* force-push rule) would collide with the rebase-then-force-push that /dev:integrate performs, so it needs a deliberate choice - protect selectively, change how integrate pushes, or accept the exposure - rather than a reflex. Current risk is low (single operator; a container only pushes its own branch) and rises when several unattended containers run concurrently, which is the feature's destination. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding.", "rejected_alternative": "Spawning a sibling issue to decide between selective protection, changing integrate's push strategy, and accepting the exposure. Turned down by the operator in favour of covering it another way. The narrower alternative of protecting feature/* immediately was already rejected at plan time because it would break /dev:integrate." } ```

jbr870 commented

2026-08-25 13:50:10 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. The /voice audio plumbing is deleted outright rather than shimmed or flagged, so there is no residue to follow up: an unattended run has nobody to talk to, and the audio path was the most host-coupled part of the image. AC-20 asserts mechanically that no audio package or socket mount survives in .devcontainer/, which is a stronger guarantee than a tracking ticket would give. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. The /voice audio plumbing is deleted outright rather than shimmed or flagged, so there is no residue to follow up: an unattended run has nobody to talk to, and the audio path was the most host-coupled part of the image. AC-20 asserts mechanically that no audio package or socket mount survives in .devcontainer/, which is a stronger guarantee than a tracking ticket would give. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. VS Code integration is removed, not deferred: the operator does not use VS Code and the lifecycle is terminal-first by requirement, so devcontainer.json and the extension list would be configuration nothing exercises - which is what rots into a misleading state. AC-13 asserts no .devcontainer/ file references an editor or GUI step. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. VS Code integration is removed, not deferred: the operator does not use VS Code and the lifecycle is terminal-first by requirement, so devcontainer.json and the extension list would be configuration nothing exercises - which is what rots into a misleading state. AC-13 asserts no .devcontainer/ file references an editor or GUI step. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. Resource isolation (ports, databases, service lifecycle) has nothing to attach to: this repo runs no services, so parallel containers have nothing to allocate or collide over. Isolation here is about blast radius, not resources, and a follow-up issue would describe work that has no trigger. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. Resource isolation (ports, databases, service lifecycle) has nothing to attach to: this repo runs no services, so parallel containers have nothing to allocate or collide over. Isolation here is about blast radius, not resources, and a follow-up issue would describe work that has no trigger. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended, and specifically because the follow-up already exists elsewhere. The slot recipe schema makes port_scheme and database mandatory, so a services-free project cannot declare a valid parallel_dev recipe at all - filed as suite issue #62, whose live case is this very repository. Spawning a sibling here would duplicate #62 rather than add anything. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended, and specifically because the follow-up already exists elsewhere. The slot recipe schema makes port_scheme and database mandatory, so a services-free project cannot declare a valid parallel_dev recipe at all - filed as suite issue #62, whose live case is this very repository. Spawning a sibling here would duplicate #62 rather than add anything. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. Being specific to this Linux host and the local Docker daemon is the intended design rather than a limitation to remove: .devcontainer/ is repo-local infra and explicitly exempt from the suite's stack-agnostic rule (CLAUDE.md, Fencing). A portability follow-up would contradict that exemption. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. Being specific to this Linux host and the local Docker daemon is the intended design rather than a limitation to remove: .devcontainer/ is repo-local infra and explicitly exempt from the suite's stack-agnostic rule (CLAUDE.md, Fencing). A portability follow-up would contradict that exemption. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. The no-changes-to-plugin/ boundary was set at dispatch and reaffirmed throughout; suite-level gaps found during this work are filed as their own issues rather than fixed inside an infra feature, which is what happened in practice (#62 already exists, and the plan-time findings are recorded on this issue). Nothing is left needing a ticket. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. The no-changes-to-plugin/ boundary was set at dispatch and reaffirmed throughout; suite-level gaps found during this work are filed as their own issues rather than fixed inside an infra feature, which is what happened in practice (#62 already exists, and the plan-time findings are recorded on this issue). Nothing is left needing a ticket. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended. Per-container Claude logins remain the clean answer IF OAuth refresh rotation turns out to be single-use, but that is exactly what precondition D-PO-61-2-3 gates, and its waiver carries an explicit tripwire to revisit before relying on unattended parallel runs. A separate issue would duplicate that tripwire while the gate is the thing that would actually fire. The operator also rejected per-container credentials at requirements time on setup-ceremony grounds, so pre-empting it would override a standing decision to avoid a problem that may not exist. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended. Per-container Claude logins remain the clean answer IF OAuth refresh rotation turns out to be single-use, but that is exactly what precondition D-PO-61-2-3 gates, and its waiver carries an explicit tripwire to revisit before relying on unattended parallel runs. A separate issue would duplicate that tripwire while the gate is the thing that would actually fire. The operator also rejected per-container credentials at requirements time on setup-ceremony grounds, so pre-empting it would override a standing decision to avoid a problem that may not exist. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Accepted as recommended, because it was absorbed rather than deferred. Surfacing credential age and workspace ahead/dirty state is already in this slice's Implementation Scope as part of the dw.sh ls dashboard - the UX and security lenses asked for the same row for different reasons (the operator's only cross-container view of work that is invisible until pushed, and credential hygiene on stopped containers). There is nothing outstanding to track. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Accepted as recommended, because it was absorbed rather than deferred. Surfacing credential age and workspace ahead/dirty state is already in this slice's Implementation Scope as part of the dw.sh ls dashboard - the UX and security lenses asked for the same row for different reasons (the operator's only cross-container view of work that is invisible until pushed, and credential hygiene on stopped containers). There is nothing outstanding to track. Authority: operator resolved this disposition directly on 2026-08-25 after reviewing the finding." } ```

jbr870 commented