role-qa: evaluate bounded reconfiguration authority for the QA seat #273

New issue

Open

opened 2026-08-12 09:27:56 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 09:27:56 +00:00

Member

Context

A QA seat was asked to apply configuration changes to a deployed service and declined. Recording the charter question so it gets decided deliberately rather than re-litigated per session.

What was blocked

Requested: edit channel pins in a cli-guard guardfile and add deployment configuration under coilyco-bridge/deploy. Both are declarative config; no product code.

role-qa denies it on two clauses:

"Do not ... deploy, release, merge product work, mutate production, or remediate failures."
"Role prose grants no executable permission."

Case for granting

Config-only edits in these repos are gated before they reach anything live. .ward/ward.yaml already carries helm-lint-sirens-deep, helm-template-sirens-deep, and compose-review-sirens-deep, and a pre-commit hook ties services/sirens-echo/deploy/sirens-deep-values.yaml to rendered/sirens-deep-bundle.txt. A bad edit fails at render, not at rollout.
Round-tripping every config change through a second seat costs a full session handoff for edits CI already validates.

Case against

Independence. A QA seat verifying a change that same seat authored is not independent verification. The read-only posture is what makes a QA pass mean something.
"Config-only" is not self-enforcing. The channel pins in services/sirens-echo/discord-mcp.mcp.kdl are the security boundary. A guardfile edit is a permission change wearing config clothes, and file type does not distinguish the two.

Open questions

If granted, is it scoped to repo edit + PR, with merge and rollout still owned by another seat?
Does authoring a change disqualify the authoring seat from verifying it? If so, does this require a second QA seat to be useful at all?
Does "configuration" need an explicit path allowlist, given that guardfiles and access policies are config by file type but authority by function?

Next owner

Kai — charter decision. No code change until scope is settled.

## Context A QA seat was asked to apply configuration changes to a deployed service and declined. Recording the charter question so it gets decided deliberately rather than re-litigated per session. ## What was blocked Requested: edit channel pins in a cli-guard guardfile and add deployment configuration under `coilyco-bridge/deploy`. Both are declarative config; no product code. `role-qa` denies it on two clauses: - "Do not ... deploy, release, merge product work, mutate production, or remediate failures." - "Role prose grants no executable permission." ## Case for granting - Config-only edits in these repos are gated before they reach anything live. `.ward/ward.yaml` already carries `helm-lint-sirens-deep`, `helm-template-sirens-deep`, and `compose-review-sirens-deep`, and a pre-commit hook ties `services/sirens-echo/deploy/sirens-deep-values.yaml` to `rendered/sirens-deep-bundle.txt`. A bad edit fails at render, not at rollout. - Round-tripping every config change through a second seat costs a full session handoff for edits CI already validates. ## Case against - Independence. A QA seat verifying a change that same seat authored is not independent verification. The read-only posture is what makes a QA pass mean something. - "Config-only" is not self-enforcing. The channel pins in `services/sirens-echo/discord-mcp.mcp.kdl` *are* the security boundary. A guardfile edit is a permission change wearing config clothes, and file type does not distinguish the two. ## Open questions 1. If granted, is it scoped to repo edit + PR, with merge and rollout still owned by another seat? 2. Does authoring a change disqualify the authoring seat from verifying it? If so, does this require a second QA seat to be useful at all? 3. Does "configuration" need an explicit path allowlist, given that guardfiles and access policies are config by file type but authority by function? ## Next owner Kai — charter decision. No code change until scope is settled.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agent-compose#273

No description provided.

Rows
Columns