gate: say what the floor ratchet actually defends

[iceteaSA]

Follow-up to your correction on #46. The refusal text taught the mechanism you got wrong, and I shipped it, so this replaces it with what the check actually defends.

What I reproduced before agreeing

squash stale(610) onto upstream(616)     ->  floor 616, gate.sh staged: 0 files
fork-before-raise, edits the floor line  ->  UU scripts/gate.sh, 1 conflict marker

A squash applies the diff rather than the branch's file contents, so master's raise survives and gate.sh is not even in the staged set. A branch that does touch the line conflicts loudly and GitHub refuses the merge. Neither path is silent, and the old text described the first one as the headline failure mode.

The silent route is the one you named: a human resolving that conflict by keeping their own side — which is what happened on this repo an hour before #46 landed. The check also covers a plain hand-edit downward, on a branch or on master, so the new text names both.

Rendered, not read off the diff

Tripped the arm with a lowered floor rather than trusting the string:

GATE FAILED: floor ratchet: this tree's workspace floor is 600 but origin/master
(408fc40) carries 618 — a squash does NOT carry a stale floor onto master (the diff
wins, and a branch that edits this line conflicts loudly), so the way a raise actually
gets dropped is a human resolving that conflict with --ours, or a hand-edit here;
re-measure on the merged tree, or set CK_GATE_FLOOR_LOWER_REASON

First attempt at that render died at inbound contracts before reaching the ratchet, because I had created the worktree without its sibling checkouts. The arm never ran, and the gate's failure was mine rather than the code's — worth mentioning because a gate that fails early looks the same as a gate whose later arm failed, if you only read the exit code.

Scope

One string. bash scripts/gate.sh exit 0 on the merged tree, workspace floor 618 >= origin/master 618 at 408fc40.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Replaces the floor ratchet refusal message so it no longer teaches a wrong mechanism. The old text claimed a fork-before-raise lowers the floor silently; actually a squash applies the diff so the raise survives, and a branch touching the line conflicts loudly. The new message names the real silent paths: a human resolving the conflict with --ours, or a hand-edit downward.

^{Written for commit 4a8a623. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

_{You’re at about 94% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="scripts/gate.sh">

<violation number="1" location="scripts/gate.sh:296">
P3: The new failure message refutes the doc comment directly above `assert_floor_not_lowered`, which still asserts the mechanism this PR is correcting. The comment at scripts/gate.sh:234-235 says a fork-before-raise branch "carries the OLD number forward in this file and merges green, silently reverting the raise", while the new message says "a squash does NOT carry a stale floor onto master (the diff wins, and a branch that edits this line conflicts loudly)" and that the raise is dropped only by a --ours resolution or a hand-edit. A reader debugging a gate failure now gets two mutually exclusive explanations of the same hazard in one function. Update the comment block (including the "Live instance" paragraph) to the corrected mechanism, or the file's own rationale rebuilds the confusion the PR set out to remove.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The new failure message refutes the doc comment directly above assert_floor_not_lowered, which still asserts the mechanism this PR is correcting. The comment at scripts/gate.sh:234-235 says a fork-before-raise branch "carries the OLD number forward in this file and merges green, silently reverting the raise", while the new message says "a squash does NOT carry a stale floor onto master (the diff wins, and a branch that edits this line conflicts loudly)" and that the raise is dropped only by a --ours resolution or a hand-edit. A reader debugging a gate failure now gets two mutually exclusive explanations of the same hazard in one function. Update the comment block (including the "Live instance" paragraph) to the corrected mechanism, or the file's own rationale rebuilds the confusion the PR set out to remove.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/gate.sh, line 296:

<comment>The new failure message refutes the doc comment directly above `assert_floor_not_lowered`, which still asserts the mechanism this PR is correcting. The comment at scripts/gate.sh:234-235 says a fork-before-raise branch "carries the OLD number forward in this file and merges green, silently reverting the raise", while the new message says "a squash does NOT carry a stale floor onto master (the diff wins, and a branch that edits this line conflicts loudly)" and that the raise is dropped only by a --ours resolution or a hand-edit. A reader debugging a gate failure now gets two mutually exclusive explanations of the same hazard in one function. Update the comment block (including the "Live instance" paragraph) to the corrected mechanism, or the file's own rationale rebuilds the confusion the PR set out to remove.</comment>

<file context>
@@ -293,7 +293,7 @@ assert_floor_not_lowered() {
       return
     fi
-    fail "floor ratchet: this tree's workspace floor is $ours but $target ($target_sha) carries $theirs — a branch forked before a raise lowers it silently and every gate still passes; rebase and re-measure on the merged tree, or set CK_GATE_FLOOR_LOWER_REASON"
+    fail "floor ratchet: this tree's workspace floor is $ours but $target ($target_sha) carries $theirs — a squash does NOT carry a stale floor onto master (the diff wins, and a branch that edits this line conflicts loudly), so the way a raise actually gets dropped is a human resolving that conflict with --ours, or a hand-edit here; re-measure on the merged tree, or set CK_GATE_FLOOR_LOWER_REASON"
     return
   fi
</file context>