feat(rules)!: a rule cannot be created, or edited into, having no trigger (#4099)
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 9s
CI & Build / integration (push) Failing after 33s
CI & Build / Python tests (push) Failing after 37s
CI & Build / TypeScript typecheck (push) Successful in 54s
CI & Build / Build & push image (push) Skipped
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 9s
CI & Build / integration (push) Failing after 33s
CI & Build / Python tests (push) Failing after 37s
CI & Build / TypeScript typecheck (push) Successful in 54s
CI & Build / Build & push image (push) Skipped
`when_to_apply` is not metadata. `rule_document` embeds a rule as
`{title} — {trigger}` / `When to apply: {trigger}\n\n{statement}`, the trigger
appearing twice so purpose dominates a short vector — the shape note 2485
measured on snippets (a 0.153 top-to-second gap against 0.010–0.023 for
everything else). Without one the document silently becomes title + statement:
a DIFFERENT shape, ranked against a corpus it does not match, with nothing to
report it. Every bar and every rank in the system assumes one shape.
`create_preference` has refused an empty trigger since it shipped. The two rule
creators defaulted it to "" — so the shape was enforced for the record kind
that guides and optional for the kind that binds.
The guard lives in the SERVICE, because both doors reach it: the MCP tools and
the frontend's fast path in routes/rulebooks.py. Written in either alone, the
other could still create a rule that never fires. The route keeps a matching
check for the STATUS CODE only (400, not the 404 it maps ValueError to).
update_rule refuses to EMPTY an existing trigger, checked after the mutation so
it covers `clear=[...]`, an emptied form input, and any route added later.
Deliberately asked as "did this edit remove one" rather than "does one exist":
a rule predating the guard has none, and refusing to save it would freeze
precisely the unreachable records that most need fixing.
Deliberately not following arose_from_id, which the human door exempts itself
from because provenance is about auditing what the AGENT changed. That reasoning
does not reach this field — a missing trigger is not a missing explanation, it
is a rule that does not work, and it fails an operator as badly as a session.
15 test fixtures across 6 files were creating rules with no trigger. They now
pass one; that they did not is the point — curation is not a guarantee.
Step 1 of milestone 416 "Retrieval stops guessing a bar". First because every
later step assumes one document shape, and it is much cheaper to guarantee
before a corpus grows than to backfill after.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
This commit is contained in:
@@ -246,7 +246,7 @@ async def get_rule(rule_id: int) -> dict:
|
||||
|
||||
|
||||
async def create_rule(
|
||||
topic_id: int, title: str, statement: str, when_to_apply: str = "",
|
||||
topic_id: int, title: str, statement: str, when_to_apply: str,
|
||||
why: str = "", how_to_apply: str = "", order_index: int = 0,
|
||||
arose_from_id: int = 0, verify_with: str = "", expires_when: str = "",
|
||||
system_ids: list[int] | None = None, force: bool = False,
|
||||
@@ -344,10 +344,14 @@ async def create_rule(
|
||||
when_to_apply: WHEN this rule fires — the trigger, not the
|
||||
instruction. State the moment or the material: "before any git
|
||||
push", "when adding a value to a CHECK-gated column", "when a
|
||||
release is being cut". Write it even though the parameter is
|
||||
optional: it is how the rule is found
|
||||
when it matters, and a rule nobody can place is a rule nobody
|
||||
applies.
|
||||
release is being cut". REQUIRED, and not as ceremony: nothing is
|
||||
preloaded, so this is the whole of how the rule is found when it
|
||||
matters — and it is half of what the rule is EMBEDDED as, so a
|
||||
rule without one is not merely hard to find, it is stored in a
|
||||
different shape from every rule it competes with. Name the SYMPTOM
|
||||
— the words someone would type while stuck — rather than the
|
||||
category: "the CI job passed locally and fails on the runner with
|
||||
a permission error" retrieves; "when touching CI config" does not.
|
||||
This field is also the rule's RETRIEVAL SURFACE — it and the
|
||||
statement are what a search is matched against, so it should
|
||||
carry the SYMPTOM, not just the situation: the words someone
|
||||
@@ -411,7 +415,7 @@ async def create_rule(
|
||||
|
||||
|
||||
async def create_project_rule(
|
||||
project_id: int, statement: str, title: str = "", when_to_apply: str = "",
|
||||
project_id: int, statement: str, when_to_apply: str, title: str = "",
|
||||
why: str = "", how_to_apply: str = "", order_index: int = 0,
|
||||
arose_from_id: int = 0, verify_with: str = "", expires_when: str = "",
|
||||
system_ids: list[int] | None = None, force: bool = False,
|
||||
|
||||
Reference in New Issue
Block a user