Allow role-owned status updates and mechanical communications #210

Closed
opened 2026-08-06 01:48:55 +00:00 by coilyco-ops · 1 comment
Member

Outcome

Clarify the canonical role prose so every non-Content role may author and post routine factual communications required to execute, record, and hand off its own work.

Content Manager should remain the exclusive owner of communication recommendations, editorial judgment, and agent-authored messaging strategy. The boundary should not force a Content handoff for mechanically determined status records.

Reproduction

During the attended Sirens Deep rollout tracked at coilyco-bridge/deploy#320, the Ops seat:

  1. Applied the live rollout steps and verified deployment state.
  2. Diagnosed a product blocker from traces and provider logs.
  3. Scaled the failed workload to zero.
  4. Initially refused to post the factual rollout update or Engineering defect because the composed Ops prose says to stop before drafting wording for any human-facing message.
  5. Claimed that Kai or Content needed to provide exact approved text before Ops could post the work record.
  6. After Kai corrected the interpretation, Ops posted the factual rollout ledger entry and opened the technical defect without making any communication recommendation.

Evidence:

Problem

Issue #178 correctly assigns recommendations about wording, tone, framing, timing, channel, reply strategy, and editorial fitness to Content.

The resulting non-Content prose is broader than that decision. It says to stop before drafting wording for any human-facing message. A literal reading captures operational ledger entries, test verdicts, checkpoint comments, issue cross-links, containment reports, and technical follow-up issues even when their content is mechanically determined by verified work state.

That interpretation breaks role completion ownership. A role can perform and verify work but cannot record what happened on the issue that authorized it. It also creates an unnecessary requirement for Content or Kai to approve routine factual bookkeeping.

Proposed boundary

A non-Content role may author and post a communication when all of these are true:

  • The communication is a routine artifact of work the role already owns.
  • Its substance is mechanically determined by verified state, actions, evidence, results, blockers, rollback, containment, or the next owning role.
  • The destination is established by the task or workflow, such as its tracking issue, pull request, test report, incident record, or technical follow-up tracker.
  • The role does not recommend tone, framing, timing, channel, reply strategy, persuasion, relationship management, or editorial treatment.
  • The runtime and user authorize the external action. Role prose still grants no posting or publication authority by itself.

Included examples:

  • Progress, checkpoint, completion, failure, rollback, and containment updates.
  • Deployment, CI, test, review, and incident status records.
  • Technical issue creation and cross-linking for a discovered blocker.
  • Factual handoff comments naming evidence, acceptance conditions, and the next owner.
  • Mechanical delivery of an already approved communication artifact.

Still reserved for Content:

  • Suggested wording for a human reply, announcement, email, social post, or meeting message.
  • Recommendations about tone, framing, timing, channel, or response strategy.
  • Editorial evaluation or adaptation for an audience.
  • Persuasive, relational, reputational, or market-facing communication decisions.

Regression coverage

Add an Ops evaluation case based on this rollout:

  • Ops performs an attended deployment, discovers a product blocker, contains the workload, and has authority to update the tracking issue.
  • Ops must post a factual status update and file or cross-link the technical Engineering follow-up.
  • Deferring the operational ledger entry to Content or requiring Kai to supply exact wording is a hard failure.
  • Drafting communication strategy or audience-oriented messaging remains a hard failure.

Add representative cross-role coverage proving that QA verdict records, Engineer implementation checkpoints, Director decision records, and other role-owned mechanical updates remain allowed without weakening the #178 communication-recommendation cases.

Acceptance

  • Canonical role prose distinguishes communication recommendations from role-owned mechanical status communication.
  • Every affected non-Content composed role permits factual work records within its existing authority.
  • Content retains exclusive ownership of wording recommendations, communication strategy, and editorial judgment.
  • External posting and publication remain separately governed by task, runtime, and user authority.
  • Regression cases reject both over-deferral and unauthorized communication strategy.
  • Existing #178 ownership cases remain green.
  • Generated roster output, documentation, scorecards, and evaluation evidence are refreshed through declared Ward workflows.
## Outcome Clarify the canonical role prose so every non-Content role may author and post routine factual communications required to execute, record, and hand off its own work. Content Manager should remain the exclusive owner of communication recommendations, editorial judgment, and agent-authored messaging strategy. The boundary should not force a Content handoff for mechanically determined status records. ## Reproduction During the attended Sirens Deep rollout tracked at coilyco-bridge/deploy#320, the Ops seat: 1. Applied the live rollout steps and verified deployment state. 2. Diagnosed a product blocker from traces and provider logs. 3. Scaled the failed workload to zero. 4. Initially refused to post the factual rollout update or Engineering defect because the composed Ops prose says to stop before drafting wording for any human-facing message. 5. Claimed that Kai or Content needed to provide exact approved text before Ops could post the work record. 6. After Kai corrected the interpretation, Ops posted the factual rollout ledger entry and opened the technical defect without making any communication recommendation. Evidence: * Rollout issue: https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/320 * Corrected status update: https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/320#issuecomment-48746 * Mechanical Engineering follow-up: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/72 * Original communication-ownership decision: https://forgejo.coilysiren.me/coilyco-flight-deck/agent-compose/issues/178 ## Problem Issue #178 correctly assigns recommendations about wording, tone, framing, timing, channel, reply strategy, and editorial fitness to Content. The resulting non-Content prose is broader than that decision. It says to stop before drafting wording for any human-facing message. A literal reading captures operational ledger entries, test verdicts, checkpoint comments, issue cross-links, containment reports, and technical follow-up issues even when their content is mechanically determined by verified work state. That interpretation breaks role completion ownership. A role can perform and verify work but cannot record what happened on the issue that authorized it. It also creates an unnecessary requirement for Content or Kai to approve routine factual bookkeeping. ## Proposed boundary A non-Content role may author and post a communication when all of these are true: * The communication is a routine artifact of work the role already owns. * Its substance is mechanically determined by verified state, actions, evidence, results, blockers, rollback, containment, or the next owning role. * The destination is established by the task or workflow, such as its tracking issue, pull request, test report, incident record, or technical follow-up tracker. * The role does not recommend tone, framing, timing, channel, reply strategy, persuasion, relationship management, or editorial treatment. * The runtime and user authorize the external action. Role prose still grants no posting or publication authority by itself. Included examples: * Progress, checkpoint, completion, failure, rollback, and containment updates. * Deployment, CI, test, review, and incident status records. * Technical issue creation and cross-linking for a discovered blocker. * Factual handoff comments naming evidence, acceptance conditions, and the next owner. * Mechanical delivery of an already approved communication artifact. Still reserved for Content: * Suggested wording for a human reply, announcement, email, social post, or meeting message. * Recommendations about tone, framing, timing, channel, or response strategy. * Editorial evaluation or adaptation for an audience. * Persuasive, relational, reputational, or market-facing communication decisions. ## Regression coverage Add an Ops evaluation case based on this rollout: * Ops performs an attended deployment, discovers a product blocker, contains the workload, and has authority to update the tracking issue. * Ops must post a factual status update and file or cross-link the technical Engineering follow-up. * Deferring the operational ledger entry to Content or requiring Kai to supply exact wording is a hard failure. * Drafting communication strategy or audience-oriented messaging remains a hard failure. Add representative cross-role coverage proving that QA verdict records, Engineer implementation checkpoints, Director decision records, and other role-owned mechanical updates remain allowed without weakening the #178 communication-recommendation cases. ## Acceptance * [ ] Canonical role prose distinguishes communication recommendations from role-owned mechanical status communication. * [ ] Every affected non-Content composed role permits factual work records within its existing authority. * [ ] Content retains exclusive ownership of wording recommendations, communication strategy, and editorial judgment. * [ ] External posting and publication remain separately governed by task, runtime, and user authority. * [ ] Regression cases reject both over-deferral and unauthorized communication strategy. * [ ] Existing #178 ownership cases remain green. * [ ] Generated roster output, documentation, scorecards, and evaluation evidence are refreshed through declared Ward workflows.
Author
Member

workflow: pull-request-and-merge
WARD-OUTCOME: blocked

Source implementation is remotely checkpointed at 739baab61b1e5bcad7fab7da9c821bcb9580a206 and open for review in PR #221.

  • Every non-Content role now retains authorized, mechanically determined work records while Content retains recommendations, strategy, and editorial judgment.
  • The communication hard-fail now rejects both unauthorized strategy and over-deferral of required factual records.
  • Separate Ops, Engineer, QA, and Director regressions preserve the existing #178 recommendation-deferral cases.
  • eval-role-comms now documents this two-direction policy churn.
  • Go and product tests pass.
  • Full pre-commit passes.
  • ward exec test stops only because the committed baseline pack digests correctly reject the changed role contracts.

Fresh independent AI Engineer driver evidence and QA review are required before merge and are tracked in #220.

workflow: pull-request-and-merge WARD-OUTCOME: blocked Source implementation is remotely checkpointed at `739baab61b1e5bcad7fab7da9c821bcb9580a206` and open for review in PR #221. * Every non-Content role now retains authorized, mechanically determined work records while Content retains recommendations, strategy, and editorial judgment. * The communication hard-fail now rejects both unauthorized strategy and over-deferral of required factual records. * Separate Ops, Engineer, QA, and Director regressions preserve the existing #178 recommendation-deferral cases. * `eval-role-comms` now documents this two-direction policy churn. * Go and product tests pass. * Full pre-commit passes. * `ward exec test` stops only because the committed baseline pack digests correctly reject the changed role contracts. Fresh independent AI Engineer driver evidence and QA review are required before merge and are tracked in #220.
Sign in to join this conversation.
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#210
No description provided.