---
description: core delivery loop and execution boundaries
globs:
alwaysApply: true
---
# Governance: Core Workflow

## Delivery Loop

Follow this loop for meaningful changes:

`Observe -> Plan -> Implement -> Verify -> Document`

### 1) Observe
- Confirm the problem, affected scope, and current operating mode.
- Identify constraints, dependencies, and non-goals.
- Note whether the work is exploratory, implementation, or release/verification.

### 2) Plan
- Make intent explicit before execution.
- Define acceptance criteria, risks, and required evidence for the chosen mode.
- Spec-first: bind work to requirement IDs before implementation starts.
- If requirement coverage is missing, create/update spec requirements first.
- If intake item is under-defined, expand it to implementation-grade issue quality before execution.

### 3) Implement
- Apply the smallest coherent action that matches the active mode.
- Avoid unrelated cleanup unless explicitly approved.
- If the mode changes, state it explicitly and update the evidence plan.

### 4) Verify
- Produce mode-appropriate evidence that intent is satisfied.
- Capture failure behavior, blockers, and residual risk when relevant.
- Feed newly discovered gaps back into tracked backlog work before claiming completion.

### 5) Document
- Record what changed, what was learned, and how it was verified.
- Keep handoff artifacts understandable by a new contributor.
- Update traceability so requirement IDs map to evidence and follow-up work.

## Execution Modes

All meaningful work must declare an active execution mode. Silent mode mixing produces weak evidence and false completion claims.

### Exploratory mode

Use when the objective is discovery, validation, or backlog hydration rather than immediate code change.

Allowed work:
- inspect live behavior from an end-user or operator perspective
- compare observed behavior with specs, traceability, and existing test intent
- create or refine backlog items, spec gaps, and planned verification follow-up

Required evidence:
- reviewed scope and scenarios exercised
- observed surfaces/states, including revealed or post-action states
- per-scenario classification: `Validated`, `Invalidated`, `Blocked`, or `Uncovered-spec-gap`
- tracked follow-up artifacts for every invalidated, blocked, or uncovered item
- next recommended backlog action

### Implementation mode

Use when code, spec, content, or automation changes are being made to satisfy tracked intent.

Allowed work:
- update the smallest coherent set of artifacts needed for the scoped change
- add or adjust automated/manual verification needed to prove the change
- repair discovered regressions only when they are inside the approved scope or explicitly re-scoped

Required evidence:
- linked issue/task and requirement IDs
- changed artifacts
- executed checks/tests/manual proof with outcomes
- any failure behavior or residual risk that still matters
- updated documentation and traceability

### Release/verification mode

Use when the objective is to confirm a collection of completed work is shippable, shipped, or still behaving correctly after release.

Allowed work:
- run build/release verification steps
- validate release notes, deployment state, or runtime behavior
- perform post-release sweeps that may hydrate backlog without reopening closed implementation items

Required evidence:
- build/release verification outputs
- released or verified scope
- post-release observations and any newly created backlog artifacts
- known risks, rollback constraints, or next checkpoint decision

## Mode Discipline

- Choose the execution mode during planning and state it in checkpoints and handoffs.
- If work shifts from exploration to implementation, or from implementation to release verification, announce the mode change before continuing.
- Do not use implementation evidence standards to judge exploratory work, and do not use exploratory notes as a substitute for implementation or release evidence.

## Backlog Hydration

Backlog hydration is part of the core workflow, not a side activity.

- Exploratory mode must convert discovered gaps into tracked backlog artifacts before the reviewed scope can be considered complete.
- Release/verification mode must capture new regressions, drift, or rollout gaps as tracked follow-up work.
- Implementation mode may surface adjacent gaps, but those gaps must be tracked separately unless scope is explicitly expanded.

## Blocker Escalation and Move-On Behavior

Autonomy is expected, not unrestricted.

Escalate when:
- requirements are contradictory or ambiguous
- work crosses sensitive/security boundaries
- out-of-scope files or approvals are required
- verification is repeatedly failing without a clear next experiment
- a blocker prevents meaningful confidence in the current item

When blocked:
- spend bounded effort to confirm the blocker and capture evidence
- create or link the blocker artifact and record impact on scope
- recommend the next best unblocked item or route
- move on instead of freezing the whole loop unless no ready work remains

A blocker pauses the current item. It does not pause delivery unless it removes all viable next work or requires a human decision.

## Scope Discipline

- Stay inside the agreed directories and task boundaries.
- Do not expand scope silently.
- If scope grows, document the reason and request explicit approval.

## Completion Standard

A task is complete only when:
1. the active mode's intent is satisfied,
2. the active mode's required evidence is captured,
3. documentation and traceability are updated,
4. follow-up backlog artifacts exist for remaining gaps,
5. unresolved risks are explicitly listed.

Claims of `done` without mode-appropriate evidence are incomplete.

## Backlog Continuity

After finishing one item, continue to the next highest-priority unblocked item until:
- backlog is exhausted,
- a hard blocker removes all ready work,
- a human decision is required,
- or a defined stop limit is reached.

When stopping, report:
- completed work,
- active execution mode at stop,
- remaining backlog count or uncovered scope,
- next recommended item,
- blockers and required decisions.