Some bugfixes

CHANGELOG.md

@@ -10,6 +10,23 @@ Release entries are curated summaries for readers. Work item traceability remain
 
 ## [Unreleased]
 
+### Changed
+
+- loop run does not fail loops or work items from round_count alone (WI-2026-06-15-001)
+
+### Removed
+
+- [RFC-0006](docs/rfc/RFC-0006.md) removes max-rounds as a loop run argument and failure condition (WI-2026-06-15-001)
+- loop run no longer accepts --max-rounds or stores max_rounds in new round artifacts (WI-2026-06-15-001)
+
+### Fixed
+
+- rfc bump rejects a version bump when no RFC or clause content changed (WI-2026-06-15-002)
+- changelog-only updates do not make a later version bump valid (WI-2026-06-15-002)
+- RFC or clause content amendments still allow the next version bump (WI-2026-06-15-002)
+- W0112 bare reference warnings include the scanned artifact field and line (WI-2026-06-15-003)
+- W0112 diagnostics include a short matched-text context for quick root-cause lookup (WI-2026-06-15-003)
+
 ## [0.9.5] - 2026-06-12
 
 0.9.5 is a reviewer-evidence and compatibility patch. It gives reviewer agents

docs/rfc/RFC-0002.md

@@ -1,9 +1,9 @@
 <!-- GENERATED: do not edit. Source: RFC-0002 -->
-<!-- SIGNATURE: sha256:dd126a9195850f89dbb0ba90abee032ce072eb83017a465fd798276b9a7dbd3f -->
+<!-- SIGNATURE: sha256:10d3e6d4fb3468159ccb4d1bb48e79bac70dee20a76c213fd8e5f1647cd502f6 -->
 
 # RFC-0002: CLI Resource Model and Command Architecture
 
-> **Version:** 0.10.2 | **Status:** normative | **Phase:** test
+> **Version:** 0.10.3 | **Status:** normative | **Phase:** test
 
 ---
 
@@ -281,6 +281,10 @@ Resource-specific lifecycle verbs implement state transitions defined in [RFC-00
    - Version bumping per semantic versioning
    - Updates changelog automatically
    - Optional: `--change <description>` for additional changelog entries
+   - MUST reject a version bump when the RFC has a stored amendment signature and no RFC or clause content has changed since that signature
+   - MUST treat version, changelog, and signature metadata as bump bookkeeping, not RFC content changes
+   - MAY establish a baseline amendment signature for RFCs that do not yet have one
+   - `--change` alone MUST remain changelog-only and MUST NOT make a later version bump valid
 
 4. `govctl rfc supersede <id> --by <replacement-id>`
    - Marks RFC as superseded by another RFC
@@ -732,6 +736,14 @@ Search is discovery across the governance corpus, not a resource-specific CRUD o
 
 ## Changelog
 
+### v0.10.3 (2026-06-15)
+
+Reject empty RFC version bumps
+
+#### Fixed
+
+- reject RFC version bumps without RFC or clause content changes
+
 ### v0.10.2 (2026-06-08)
 
 Clarify init-skills skill bundle installation

gov/rfc/RFC-0002/clauses/C-LIFECYCLE-VERBS.toml

@@ -6,7 +6,10 @@ title = "Resource-Specific Lifecycle Verbs"
 kind = "normative"
 status = "active"
 since = "0.1.0"
-tags = ["cli", "lifecycle"]
+tags = [
+    "cli",
+    "lifecycle",
+]
 
 [content]
 text = """
@@ -26,6 +29,10 @@ Resource-specific lifecycle verbs implement state transitions defined in [[RFC-0
    - Version bumping per semantic versioning
    - Updates changelog automatically
    - Optional: `--change <description>` for additional changelog entries
+   - MUST reject a version bump when the RFC has a stored amendment signature and no RFC or clause content has changed since that signature
+   - MUST treat version, changelog, and signature metadata as bump bookkeeping, not RFC content changes
+   - MAY establish a baseline amendment signature for RFCs that do not yet have one
+   - `--change` alone MUST remain changelog-only and MUST NOT make a later version bump valid
 
 4. `govctl rfc supersede <id> --by <replacement-id>`
    - Marks RFC as superseded by another RFC

gov/rfc/RFC-0002/rfc.toml

@@ -3,20 +3,20 @@
 [govctl]
 id = "RFC-0002"
 title = "CLI Resource Model and Command Architecture"
-version = "0.10.2"
+version = "0.10.3"
 status = "normative"
 phase = "test"
 owners = ["@govctl-org"]
 created = "2026-01-19"
-updated = "2026-06-08"
+updated = "2026-06-15"
 tags = [
     "cli",
     "editing",
     "lifecycle",
     "validation",
     "release",
 ]
-signature = "dd126a9195850f89dbb0ba90abee032ce072eb83017a465fd798276b9a7dbd3f"
+signature = "10d3e6d4fb3468159ccb4d1bb48e79bac70dee20a76c213fd8e5f1647cd502f6"
 
 [[sections]]
 title = "Summary"
@@ -36,6 +36,12 @@ clauses = [
     "clauses/C-SEARCH-COMMAND.toml",
 ]
 
+[[changelog]]
+version = "0.10.3"
+date = "2026-06-15"
+notes = "Reject empty RFC version bumps"
+fixed = ["reject RFC version bumps without RFC or clause content changes"]
+
 [[changelog]]
 version = "0.10.2"
 date = "2026-06-08"

gov/rfc/RFC-0006/clauses/C-LOOP-COMMAND-SURFACE.toml

@@ -30,11 +30,13 @@ The canonical loop subcommands are:
 2. `loop show LOOP-ID`: read one persisted loop state by loop ID. This command MUST be read-only.
 3. `loop start [--id LOOP-ID] WI-ID...`: create or reuse a loop for an explicit `work` field set.
 4. `loop resume LOOP-ID`: select and display an existing non-terminal loop by loop ID. This command MUST be read-only and MUST NOT advance rounds.
-5. `loop run LOOP-ID [--work WI-ID ...] [--max-rounds N]`: advance the local round protocol for an existing loop state.
+5. `loop run LOOP-ID [--work WI-ID ...]`: advance the local round protocol for an existing loop state.
 6. `loop replan LOOP-ID`: recompute the dependency closure for the current explicit `work` field set.
 7. `loop add LOOP-ID work WI-ID`: add a Work Item ID to the loop's editable `work` field and replan.
 8. `loop remove LOOP-ID work WI-ID`: remove a Work Item ID from the loop's editable `work` field and replan.
 
+`loop run` MUST NOT accept a maximum-rounds argument or any other caller retry-budget argument. Repeated execution limits belong to callers and MUST NOT be persisted in loop state or round artifacts.
+
 The `work` field is the only canonical user-facing field name for the loop's explicit work set. Implementations MUST accept `wi` as a shorthand alias for `work`. User-facing help SHOULD prefer `loop add LOOP-ID work WI-ID` and `loop remove LOOP-ID work WI-ID` while documenting the alias.
 
 **Discovery semantics:**
@@ -59,4 +61,4 @@ Targeted run selection MUST NOT replace, shrink, expand, or otherwise mutate the
 
 **Rationale:**
 
-The loop command namespace coordinates several governed resources but stores its own local execution state, so it is neither a governed artifact resource nor a simple single global command. Existing-loop operations use positional `LOOP-ID` arguments to match the rest of the CLI's noun/verb/object shape. Stable argument roles prevent hidden mode switches: positional work item IDs in `add` and `remove` are field values for the loop's `work` field, while `--work` is the explicit work-item execution selector. Keeping the field position visible preserves the CLI edit model while making loop-specific replanning a domain side effect of changing the field. Reusing `run` as the round-protocol advancement command preserves existing skill guidance while removing the misleading interpretation that govctl itself implements code."""
+The loop command namespace coordinates several governed resources but stores its own local execution state, so it is neither a governed artifact resource nor a simple single global command. Existing-loop operations use positional `LOOP-ID` arguments to match the rest of the CLI's noun/verb/object shape. Stable argument roles prevent hidden mode switches: positional work item IDs in `add` and `remove` are field values for the loop's `work` field, while `--work` is the explicit work-item execution selector. Keeping the field position visible preserves the CLI edit model while making loop-specific replanning a domain side effect of changing the field. Reusing `run` as the round-protocol advancement command preserves existing skill guidance while removing the misleading interpretation that govctl itself implements code. Excluding retry-budget flags keeps the command surface small and leaves autonomous execution policy to callers."""

gov/rfc/RFC-0006/clauses/C-LOOP-LIFECYCLE.toml

@@ -19,7 +19,7 @@ A loop MUST have exactly one of the following lifecycle states:
 2. **active** — The loop is currently executing rounds on work items.
 3. **paused** — Execution stopped before a terminal outcome and may be resumed.
 4. **completed** — All work items in the resolved loop set reached non-failed terminal loop outcomes (`done` or `cancelled`) without any `failed` or `blocked` loop outcomes.
-5. **failed** — A failure condition was met (max rounds exceeded, critical error, failed work item, or blocked dependency chain).
+5. **failed** — An unrecoverable failure condition was met, such as a critical local-state error, an explicit failed work item, or a blocked dependency chain.
 
 Valid transitions:
 - pending → active (loop execution begins)
@@ -36,4 +36,6 @@ Invalid transitions (MUST be rejected):
 - pending → failed (cannot fail without being active)
 - paused → completed (completion requires active execution)
 
-Rationale: The loop lifecycle provides clear semantics for tracking execution progress and enables resumption after interruption. A distinct `paused` state avoids overloading `pending`, which means execution has not started. Terminal states (completed, failed) indicate the loop has finished and cannot be restarted."""
+Round count is audit metadata. Implementations MUST NOT infer loop failure, Work Item failure, or dependency blockage from round count alone.
+
+Rationale: The loop lifecycle provides clear semantics for tracking execution progress and enables resumption after interruption. A distinct `paused` state avoids overloading `pending`, which means execution has not started. Terminal states (completed, failed) indicate the loop has finished and cannot be restarted. Keeping round count out of failure semantics preserves the separation between govctl's local round protocol and caller-level retry policy."""

gov/rfc/RFC-0006/clauses/C-LOOP-RESUMPTION.toml

@@ -14,10 +14,10 @@ A loop MAY be paused and resumed across CLI invocations or agent sessions.
 
 If a loop implementation supports resumption, it MUST:
 
-1. Persist loop state using the storage contract defined by [[RFC-0006:C-LOOP-STATE-STORAGE]]
-2. Resume existing loop operations by positional `LOOP-ID` as defined by [[RFC-0006:C-LOOP-COMMAND-SURFACE]]
-3. Resume from the last recorded state and open round artifact rather than starting fresh when the requested loop state exists and is non-terminal
-4. Reject operations that require a non-terminal loop when the loop is terminal
+1. Persist loop state using the storage contract defined by [[RFC-0006:C-LOOP-STATE-STORAGE]].
+2. Resume existing loop operations by positional `LOOP-ID` as defined by [[RFC-0006:C-LOOP-COMMAND-SURFACE]].
+3. Resume from the last recorded state and open round artifact rather than starting fresh when the requested loop state exists and is non-terminal.
+4. Reject operations that require a non-terminal loop when the loop is terminal.
 
 **Discovery semantics:**
 
@@ -31,18 +31,19 @@ A stored loop matches a requested work set when its current editable `work` fiel
 
 When resuming a loop:
 
-- Work items in `done` loop state MUST NOT be selected for new round work
-- Work items in `active` loop state MAY be selected again only through the local round protocol
-- Work items in `blocked`, `failed`, or `cancelled` loop state MUST remain terminal for dependency planning unless an explicit scope mutation recomputes a dependency-derived `blocked` outcome
-- Work items in `pending` loop state MAY be selected in dependency order when opening a round unless an explicit run selector narrows execution per [[RFC-0006:C-LOOP-COMMAND-SURFACE]]
-- If `loop.current_round` points at an open round artifact, `loop run` MUST validate or reject that artifact before opening another round
+- Work items in `done` loop state MUST NOT be selected for new round work.
+- Work items in `active` loop state MAY be selected again only through the local round protocol.
+- Work items in `blocked`, `failed`, or `cancelled` loop state MUST remain terminal for dependency planning unless an explicit scope mutation recomputes a dependency-derived `blocked` outcome.
+- Work items in `pending` loop state MAY be selected in dependency order when opening a round unless an explicit run selector narrows execution per [[RFC-0006:C-LOOP-COMMAND-SURFACE]].
+- If `loop.current_round` points at an open round artifact, `loop run` MUST validate or reject that artifact before opening another round.
+- Prior round counts MUST NOT prevent a non-terminal work item from being selected again when it is otherwise ready.
 
 **State preservation:**
 
 The loop state MUST preserve:
 
 - Execution status of each current work item (pending, active, done, failed, blocked, cancelled)
-- Round count for each current work item
+- Round count for each current work item as audit metadata
 - Last selected round for each current work item when known
 - Current editable `work` field values
 - Dependency graph at last planning time
@@ -55,4 +56,4 @@ The loop state MAY preserve:
 - Guard execution result summaries
 - Agent context and decision history inside local round artifacts
 
-Rationale: Resumption enables long-running multi-WI loops to survive agent session boundaries without losing progress. Positional loop IDs provide precise lookup that matches the CLI's noun/verb/object shape. Work-set matching remains a discovery convenience for start/list workflows, not an execution command mode. By persisting state independently of work item files, we maintain the separation between execution state and governed artifacts. Scope mutation makes the stored work set current rather than historical, so discovery continues to match the loop the user intends to resume."""
+Rationale: Resumption enables long-running multi-WI loops to survive agent session boundaries without losing progress. Positional loop IDs provide precise lookup that matches the CLI's noun/verb/object shape. Work-set matching remains a discovery convenience for start/list workflows, not an execution command mode. By persisting state independently of work item files, govctl maintains the separation between execution state and governed artifacts. Scope mutation makes the stored work set current rather than historical, so discovery continues to match the loop the user intends to resume. Round counts remain useful for audit and display without becoming hidden retry policy."""

gov/rfc/RFC-0006/clauses/C-LOOP-STATE-STORAGE.toml

@@ -40,14 +40,14 @@ The optional `loop.current_round` value records the latest loop-level round numb
 
 The `[dependencies]` table MUST contain one entry for each work item in `loop.resolved`. Each dependency entry MUST be an array of Work Item IDs. Each dependency ID MUST also appear in `loop.resolved`. Dependency arrays MUST NOT contain duplicate Work Item IDs.
 
-The `[items.<WI-ID>]` table MUST contain one entry for each work item in `loop.resolved`. Each item `status` MUST be one of the loop-level work item statuses defined by [[RFC-0006:C-WORK-ITEM-INTERACTION]]. Each `round_count` MUST be a non-negative integer. The optional `last_round` value records the last loop-level round that selected or updated the item.
+The `[items.<WI-ID>]` table MUST contain one entry for each work item in `loop.resolved`. Each item `status` MUST be one of the loop-level work item statuses defined by [[RFC-0006:C-WORK-ITEM-INTERACTION]]. Each `round_count` MUST be a non-negative integer. The optional `last_round` value records the last loop-level round that selected or updated the item. `round_count` and `last_round` are audit metadata and MUST NOT encode retry budgets or failure policy.
 
 Loop state storage MUST be keyed by loop ID, not by work item ID. A multi-work-item loop MUST have one shared loop state root so dependency planning, failure propagation, and resumption use the same authoritative state.
 
-Loop round artifacts MUST be stored under `.govctl/loops/<loop-id>/rounds/round-NNN.toml`, where `NNN` is the three-digit loop-level round number. A round artifact MUST identify the loop ID, round number, selected work item IDs, round state, summary evidence, blockers, and note candidates. Round artifacts are local execution trace and MUST NOT be written to Work Item fields.
+Loop round artifacts MUST be stored under `.govctl/loops/<loop-id>/rounds/round-NNN.toml`, where `NNN` is the three-digit loop-level round number. A round artifact MUST identify the loop ID, round number, selected work item IDs, round state, summary evidence, blockers, and note candidates. Round artifacts MUST NOT encode maximum round limits or caller retry budgets. Round artifacts are local execution trace and MUST NOT be written to Work Item fields.
 
 Round artifacts MAY mention Work Item IDs when evidence applies to specific work, but the storage root is loop-level. Implementations MUST NOT require per-work-item round directories for the canonical state model.
 
 Loop state is local execution state, not a governed artifact. Deleting `.govctl/loops/` MUST NOT invalidate RFCs, ADRs, Work Items, Guards, or rendered governance projections, but MAY remove resumability and local execution trace.
 
-Rationale: A loop can drive multiple work items, so a per-work-item state root cannot represent the loop lifecycle, dependency graph, aggregate outcome, or round evidence. A single loop directory keeps execution state separate from Work Item files while preserving enough protocol state for resumption. Canonical generated loop IDs follow the existing artifact style of a type prefix, date, and sequence while avoiding collision-prone plain-text IDs.'''
+Rationale: A loop can drive multiple work items, so a per-work-item state root cannot represent the loop lifecycle, dependency graph, aggregate outcome, or round evidence. A single loop directory keeps execution state separate from Work Item files while preserving enough protocol state for resumption. Canonical generated loop IDs follow the existing artifact style of a type prefix, date, and sequence while avoiding collision-prone plain-text IDs. Keeping retry budgets out of persisted loop state prevents caller policy from becoming hidden local-state semantics.'''