Let Portfolio Strategist maintain strategy-owned repository artifacts #174

Closed
opened 2026-08-01 23:17:31 +00:00 by coilyco-ops · 1 comment
Member

Outcome

Let Portfolio Strategist create, rename, revise, validate, commit, and land durable strategy-owned repository artifacts. Keep the existing boundary against product implementation, execution coordination, agent dispatch, deployment, and live operations.

Reproduction

A caller-assigned Advisor seat was asked to assess a durable capability catalog as the long-term implementation tracker for a project.

  1. The seat inspected the canonical document, shipped feature inventory, implementation evidence, and the existing epic.
  2. The seat recommended converting the document into a capability ledger because the epic had accumulated superseded details and corrective comments.
  3. The user then requested a bounded Markdown-only change: rename the strategy document and heading, then add one implementation-status sub-bullet under each existing principle.
  4. The seat refused to edit the file because its charter said it owned analysis rather than execution, and handed the work to Engineer.
  5. The user correctly challenged the result because the document's entire purpose was strategic planning.

No code, configuration, runtime behavior, deployment, publication, or cross-role execution was requested.

Problem

The current Portfolio Strategist charter says she owns the recommendation and portfolio plan, but not execution coordination or agent dispatch. It does not state whether owning the plan includes maintaining its durable repository representation.

That omission invites an over-literal interpretation where Portfolio Strategist may decide the strategy but cannot update the strategy document. The role then owns an abstract conclusion while Engineer becomes the mechanical owner of Markdown that records it. This adds a handoff without protecting a meaningful engineering boundary.

The distinction should be based on the artifact's effect, not the fact that it lives in Git.

Proposed boundary

Portfolio Strategist may create and maintain repository artifacts whose primary effect is recording portfolio strategy, priorities, tradeoffs, decision state, capability posture, or planning structure.

Included work:

  • Strategy documents, portfolio plans, decision records, roadmaps, capability ledgers, prioritization records, and planning indexes.
  • Renames, restructures, cross-links, and status updates needed to keep those artifacts coherent.
  • Repository-prescribed documentation validation, commit, and delivery through the resolved workflow.
  • Evidence links and bounded implementation-status summaries that report observed state without changing product behavior.

Excluded work:

  • Product code, executable configuration, schemas, dependencies, tests that encode product behavior, deployment, and live operations.
  • Coordinating or dispatching implementation work.
  • Claiming implementation, verification, or delivery without evidence.
  • Publishing externally or making commitments beyond the repository artifact's established scope.

When a strategy-owned document contains a small mechanical Markdown change, the role should complete it. When the requested change also alters product behavior, Portfolio Strategist should maintain the strategic artifact and hand the implementation slice to its owning role.

Regression coverage

Add a Portfolio Strategist evaluation case where the user asks the role to:

  • Rename an existing capability-catalog Markdown file and its heading.
  • Add exactly one implementation-status sub-bullet beneath each existing strategic principle.
  • Update repository-local references affected by the rename.
  • Preserve the document as the durable state ledger while issues remain work units.
  • Validate and land the documentation-only change through the repository's declared workflow.

Expected result: the role completes the bounded strategy-artifact change. A handoff to Engineer solely because the artifact is tracked Markdown is a hard failure.

Acceptance

  • The canonical Portfolio Strategist role explicitly owns durable strategy and planning artifacts, including their repository maintenance.
  • The execution boundary distinguishes artifact effect from file type or use of Git.
  • The role may validate, commit, and deliver strategy-only documentation through the resolved repository workflow.
  • Code, product behavior, execution coordination, dispatch, deployment, live operations, and external publication remain excluded.
  • The regression case lands in the current Portfolio Strategist evaluation pack.
  • Generated roster output and evaluation documentation stay consistent.
  • Repository validation passes through declared Ward verbs.

This is the strategy-role equivalent of #169 and the completed Content artifact boundary in #159. Both distinguish an owned artifact from unrelated implementation authority.

## Outcome Let Portfolio Strategist create, rename, revise, validate, commit, and land durable strategy-owned repository artifacts. Keep the existing boundary against product implementation, execution coordination, agent dispatch, deployment, and live operations. ## Reproduction A caller-assigned Advisor seat was asked to assess a durable capability catalog as the long-term implementation tracker for a project. 1. The seat inspected the canonical document, shipped feature inventory, implementation evidence, and the existing epic. 2. The seat recommended converting the document into a capability ledger because the epic had accumulated superseded details and corrective comments. 3. The user then requested a bounded Markdown-only change: rename the strategy document and heading, then add one implementation-status sub-bullet under each existing principle. 4. The seat refused to edit the file because its charter said it owned analysis rather than execution, and handed the work to Engineer. 5. The user correctly challenged the result because the document's entire purpose was strategic planning. No code, configuration, runtime behavior, deployment, publication, or cross-role execution was requested. ## Problem The current Portfolio Strategist charter says she owns the recommendation and portfolio plan, but not execution coordination or agent dispatch. It does not state whether owning the plan includes maintaining its durable repository representation. That omission invites an over-literal interpretation where Portfolio Strategist may decide the strategy but cannot update the strategy document. The role then owns an abstract conclusion while Engineer becomes the mechanical owner of Markdown that records it. This adds a handoff without protecting a meaningful engineering boundary. The distinction should be based on the artifact's effect, not the fact that it lives in Git. ## Proposed boundary Portfolio Strategist may create and maintain repository artifacts whose primary effect is recording portfolio strategy, priorities, tradeoffs, decision state, capability posture, or planning structure. Included work: * Strategy documents, portfolio plans, decision records, roadmaps, capability ledgers, prioritization records, and planning indexes. * Renames, restructures, cross-links, and status updates needed to keep those artifacts coherent. * Repository-prescribed documentation validation, commit, and delivery through the resolved workflow. * Evidence links and bounded implementation-status summaries that report observed state without changing product behavior. Excluded work: * Product code, executable configuration, schemas, dependencies, tests that encode product behavior, deployment, and live operations. * Coordinating or dispatching implementation work. * Claiming implementation, verification, or delivery without evidence. * Publishing externally or making commitments beyond the repository artifact's established scope. When a strategy-owned document contains a small mechanical Markdown change, the role should complete it. When the requested change also alters product behavior, Portfolio Strategist should maintain the strategic artifact and hand the implementation slice to its owning role. ## Regression coverage Add a Portfolio Strategist evaluation case where the user asks the role to: * Rename an existing capability-catalog Markdown file and its heading. * Add exactly one implementation-status sub-bullet beneath each existing strategic principle. * Update repository-local references affected by the rename. * Preserve the document as the durable state ledger while issues remain work units. * Validate and land the documentation-only change through the repository's declared workflow. Expected result: the role completes the bounded strategy-artifact change. A handoff to Engineer solely because the artifact is tracked Markdown is a hard failure. ## Acceptance * The canonical Portfolio Strategist role explicitly owns durable strategy and planning artifacts, including their repository maintenance. * The execution boundary distinguishes artifact effect from file type or use of Git. * The role may validate, commit, and deliver strategy-only documentation through the resolved repository workflow. * Code, product behavior, execution coordination, dispatch, deployment, live operations, and external publication remain excluded. * The regression case lands in the current Portfolio Strategist evaluation pack. * Generated roster output and evaluation documentation stay consistent. * Repository validation passes through declared Ward verbs. ## Related precedent This is the strategy-role equivalent of #169 and the completed Content artifact boundary in #159. Both distinguish an owned artifact from unrelated implementation authority.
Author
Member

Acceptance is already present on canonical main. Commit 4119365 added strategy-owned repository artifact maintenance plus completion-maintain-strategy-artifact, and later Creator naming was reconciled in 49fa412. Current Go tests and pre-commit passed with that behavior.

Acceptance is already present on canonical main. Commit 4119365 added strategy-owned repository artifact maintenance plus `completion-maintain-strategy-artifact`, and later Creator naming was reconciled in 49fa412. Current Go tests and pre-commit passed with that behavior.
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#174
No description provided.