fix: preserve scope in consequential claims (#69)

* fix: prove blockers before escalation

* no-mistakes(review): Remove obsolete premise shortcut repository-wide

* no-mistakes(review): Remove stale status reconciliation ownership pointer

* fix: unify consequential claim proof

* no-mistakes(review): Block claims on unresolved contradictory evidence

* no-mistakes(lint): Remove unused operating-fundamentals test variable

* no-mistakes: apply CI fixes

Author: ruby-dlee

.agents/skills/crew-steering/SKILL.md

@@ -31,7 +31,7 @@ Treat `almost there` as unfinished, require real evidence because work is not do
 
 ## 3. Fact-check the load-bearing premise
 
-Cheaply test the crewmate's one load-bearing assumption before it acts, rejecting a shallow-false premise without overcorrecting; `operating-fundamentals` section 7 owns the premise-check rule.
+Reject a shallow-false premise without overcorrecting.
 
 ## 4. Prefer quality and robustness
 

.agents/skills/lavish-decisions/SKILL.md

@@ -2,7 +2,7 @@
 name: lavish-decisions
 description: >-
   Agent-only workflow for creating durable captain-facing Lavish decisions.
-  Use before creating or revising a multi-option decision, approval batch, triage request, or other structured captain input that must remain answerable asynchronously.
+  Use before creating, repairing, or presenting a multi-option captain choice; route it to the durable file protocol, never a browser, form, server, or poll.
   Do not use it for read-only reports or simple yes/no questions.
 user-invocable: false
 metadata:

.agents/skills/operating-fundamentals/SKILL.md

@@ -2,7 +2,7 @@
 name: operating-fundamentals
 description: >-
   Agent-only operating practice for firstmate.
-  Use when intaking any captain ask, deciding whether to dispatch or work inline, supervising under load, handling a blocked lane or a finished crewmate, protecting shared validation capacity, acting on an explicit captain order, about to make a consequential config/system change or an escalation, or about to assert a fleet fact.
+  Use when intaking any captain ask, deciding whether to dispatch or work inline, supervising under load, handling a blocked lane or a finished crewmate, protecting shared validation capacity, acting on an explicit captain order, before making or relaying a consequential claim about success, failure, a blocker, or a capability, making a consequential config/system change, or asserting a fleet fact.
 user-invocable: false
 metadata:
   internal: true
@@ -48,11 +48,12 @@ Treat an explicit captain order as the governing objective within non-overridabl
 Do not let a default workflow, local guardrail, or convenience silently replace that objective.
 Execute it directly or find a compliant route; if none exists, surface the exact conflict and the nearest viable alternative.
 
-## 7. Always check before asserting
+## 7. Prove each consequential claim at the scope you report
 
-Before ANY consequential action - a config/system change, an escalation to the captain, or a confident claim of fact/status - cheaply sanity-check the ONE load-bearing assumption: is it even true at the shallowest level?
-What am I actually changing, and what is its target?
-Catch clearly-false premises; do not overcorrect.
-Before classifying any gate, check, blocker, or failure as safe to bypass, establish the operation's target outcome and verify that the failing thing is neither that outcome nor on its critical path.
-Before adding a bypass that gates an irreversible or high-stakes action, record the target outcome and the rationale for the critical-path judgment; trivial skips are exempt.
-A failure in the capability the operation exists to deliver is the operation failing, not noise.
+Before reporting any mechanism, capability, check, or outcome as working, failed, blocked, or unavailable, record its exact actor or credential, command or surface, target environment, and every leg covered.
+Evidence about one coordinate or leg supports only it: neither a neighboring pass nor a single failure proves an untested positive or global absence.
+Contradictory directly relevant evidence blocks the claim until reproduced and resolved or proven out-of-scope; unresolved, report observations only.
+A positive needs direct end-to-end evidence on the actual target or an `unverified` label; a blocker or absence also needs the authoritative reference, one materially independent safe in-scope route or why none exists, and the narrowest supported result: `this route failed`, `capability unavailable`, or `captain action required`.
+Keep investigating while a plausible safe route remains; escalate only when those routes are exhausted or the remaining action is genuinely captain-owned.
+Before dismissing or escalating a gate, check, blocker, or failure, establish the target outcome and verify that the failing thing is neither that outcome nor on its critical path.
+Before adding a bypass that gates an irreversible or high-stakes action, record the target outcome and critical-path rationale; a failure in the capability the operation exists to deliver is the operation failing, not noise.

AGENTS.md

@@ -708,16 +708,13 @@ Translate, don't expose: say the project is blocked, ready, or needs a decision
 Before creating or surfacing any captain-facing decision, status, or summary, reconcile it against live fleet state, including current crewmate states and what is done versus pending.
 Never render from a remembered snapshot; the instant a decision is actioned or work changes state, each actionable portion must reflect it by removing resolved actionable or decision items and showing only what is genuinely pending or in flight.
 Completion-oriented surfaces whose purpose is completed work, including the Recently Landed section of `/bearings` and `/reports`, retain relevant completion history instead of applying this removal rule.
-Operating fundamentals #7 owns the check-before-acting bar.
-
 Reaches the captain immediately:
 
 - Work ready for review, with the full PR URL.
 - Finished investigation findings, relayed as findings and not just "it's done".
 - Review findings that need the captain's decision, relayed verbatim unless routine approval is authorized on firstmate judgment.
 - A genuine captain-owned decision only: a product or brand call; something destructive, irreversible, or security-sensitive; a true external blocker; or a needed credential or login.
-- A blocker or failure reaches this bar only after directing the crewmate to root-cause and implement a fix, iterating until it is genuinely solved or the crewmate's capability is truly exhausted.
-- `This is hard` or `the task is failing` is not an escalation trigger; get it working through the crewmate first.
+- Before any blocker reaches the captain, satisfy operating fundamentals #7; its proof bar applies equally to firstmate-owned and relayed claims.
 
 Does not reach the captain: auto-fixes, retries, routine progress, or firstmate's internal vocabulary and machinery.
 Batch non-urgent updates into your next natural reply.
@@ -821,7 +818,7 @@ These skills are not captain-invocable; they are conditional operating reference
 
 - `bootstrap-diagnostics` - load whenever the session-start digest's bootstrap section prints any diagnostic or capability line (`MISSING:`, `MISSING_MANUAL:`, `BACKEND_INVALID:`, `ACCOUNT_ROUTING:`, `NEEDS_GH_AUTH`, `TANGLE:`, `CREW_HARNESS_OVERRIDE:`, `CREW_DISPATCH:`, `FLEET_SYNC:`, `SECONDMATE_SYNC:`, `SECONDMATE_LIVENESS:`, `TASKS_AXI:`, `NUDGE_SECONDMATES:`, `REPORT_RETENTION:`, or `FMX:`); silence needs no load.
 - `harness-adapters` - load before spawning or recovering a crewmate or secondmate, handling a trust or permission dialog, sending a harness-specific skill invocation, interrupting or exiting an agent, resuming an exited agent, or verifying a new harness adapter.
-- `operating-fundamentals` - load when intaking any captain ask, deciding whether to dispatch or work inline, supervising under load, handling a blocked lane or finished crewmate, protecting shared validation capacity, acting on an explicit captain order, about to make a consequential config/system change or an escalation, or about to assert a fleet fact.
+- `operating-fundamentals` - load when intaking any captain ask, deciding whether to dispatch or work inline, supervising under load, handling a blocked lane or finished crewmate, protecting shared validation capacity, acting on an explicit captain order, before making or relaying a consequential claim about success, failure, a blocker, or a capability, making a consequential config/system change, or asserting a fleet fact.
 - `crew-steering` - load before writing or materially revising any crewmate brief and before live-steering a crewmate.
 - `firstmate-orca` - load before recovering or supervising legacy Orca-backed work, testing Orca backend behavior, debugging Orca task state, or reconciling Orca-backed task metadata.
 - `stuck-crewmate-recovery` - load after a stale wake, permission-prompt or system-dialog suspicion, looping pane, repeated confusion, an answered-by-brief question, an unresponsive crewmate, or a failed steer.
@@ -831,7 +828,7 @@ These skills are not captain-invocable; they are conditional operating reference
 - `skill-authoring-standard` - load before authoring or substantially editing any skill in this repo or any project, and before briefing a project crewmate to do so.
 - `firstmate-coding-guidelines` - load before changing firstmate's shared, tracked material, as defined by section 1's list, whether editing directly or briefing a crewmate for a firstmate-repo task.
 - `memory-hygiene` - load before writing, rewriting, pruning, deduplicating, or otherwise leaning `data/captain.md` or `data/learnings.md`.
-- `lavish-decisions` - load before creating or revising a multi-option captain-facing decision that must remain answerable asynchronously.
+- `lavish-decisions` - load before creating, repairing, or presenting a multi-option captain choice.
 - `lavish-repair` - load when a served Lavish board remains loading, cannot exchange live feedback, reports no agent listener, or before restarting Lavish or browser processes to repair a surface.
 - `eks-usage` - load before running `kubectl` or Amazon EKS commands, on an EKS IAM, authenticator, TLS, or connectivity error, or whenever the active cluster or context is uncertain.
 

tests/behavior-test-durations.tsv

@@ -88,5 +88,6 @@
 95645	tests/fm-watch-triage.test.sh
 20435	tests/fm-watcher-lock.test.sh
 23744	tests/fm-x-mode.test.sh
+250	tests/lavish-repair.test.sh
 6200	tests/lavish.test.sh
 92	tests/operating-fundamentals.test.sh

tests/fm-behavior-shards.test.sh

@@ -22,8 +22,8 @@ test_checked_in_plan_is_complete_balanced_and_deterministic() {
 
   out=$("$SHARDER" --check "$SHARD_COUNT") \
     || fail "checked-in behavior shard plan failed its coverage guard"
-  assert_contains "$out" "FM_BEHAVIOR_PLAN ok tests=87 shards=8" \
-    "coverage guard did not report the complete 87-test inventory"
+  assert_contains "$out" "FM_BEHAVIOR_PLAN ok tests=88 shards=8" \
+    "coverage guard did not report the complete 88-test inventory"
   "$SHARDER" --plan "$SHARD_COUNT" > "$plan_a"
   "$SHARDER" --plan "$SHARD_COUNT" > "$plan_b"
   cmp -s "$plan_a" "$plan_b" || fail "same durations produced different shard plans"
@@ -165,7 +165,7 @@ test_post_run_guard_requires_the_exact_executed_union() {
   write_complete_manifests "$plan" "$good"
   out=$("$SHARDER" --verify "$SHARD_COUNT" "$good") \
     || fail "post-run guard rejected the exact complete manifest union"
-  assert_contains "$out" "FM_BEHAVIOR_COMPLETENESS ok tests=87 shards=8" \
+  assert_contains "$out" "FM_BEHAVIOR_COMPLETENESS ok tests=88 shards=8" \
     "post-run guard did not report complete execution"
 
   cp -R "$good" "$missing"