CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 14s
CI & Build / TypeScript typecheck (push) Successful in 53s
CI & Build / integration (push) Successful in 1m10s
CI & Build / Python tests (push) Successful in 1m54s
CI & Build / Build & push image (push) Successful in 31s
report_preference searched one constant string when a task closed and handed matches back as update_task's reply_preferences. Milestone 500 step 3 delivers the reply shapes and the preferences mounted beside them on the moments, so the arm goes, whole (rule 22): - services/reply_preferences.py, the REPORT_PREFERENCE RuleArm, its re-scorer and corpus entries, and the REPORTPREF constants - update_task's reply_preferences block and its cue; the docstring now points at moment_rules - the fixed_query field and the fixed_query_never_clears warning: this arm was the only one that set it, so the concept and the cannot_decline exemption go with it - the two Settings fields for its floor and budget - migration 0121 deletes its rows (logs, judgments, rule-usage events, tuning history, settings keys), operator-approved 2026-10-09. Without it the readout would call the source unregistered and its surfacings would count as ambient. The unindexed rule_usage delete is bounded by created_at. #5496 (step 4 of milestone 500). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
60 lines
2.3 KiB
Python
60 lines
2.3 KiB
Python
"""retire the report_preference arm's rows (milestone 500 step 4)
|
|
|
|
Revision ID: 0121
|
|
Revises: 0120
|
|
Create Date: 2026-10-09
|
|
|
|
The fixed-question arm that searched for completion-report preferences when a
|
|
task closed is gone: the reply shapes and the preferences mounted beside them
|
|
now arrive on the moments (milestone 500 step 3). Its rows go with it (rule
|
|
22 — no legacy to preserve), because each one would otherwise mean something
|
|
different once the arm is no longer registered:
|
|
|
|
- `retrieval_logs` / `retrieval_judgments` — a source missing from the
|
|
registry reads as `unregistered_source`, whose advice is "add it to the
|
|
registry": the opposite of what happened.
|
|
- `rule_usage_events` — a source missing from `RANKED_SOURCES` reads as
|
|
ambient, so its surfacings would silently move into the other column of
|
|
every rule's pull-through.
|
|
- `retrieval_tuning_events` — the tuning history of a surface that no longer
|
|
exists.
|
|
- `settings` — the arm's floor and budget keys, which nothing reads.
|
|
|
|
COST IS BOUNDED BY AN INDEX, NOT BY THE TABLE. A migration runs at boot
|
|
against the live tables, which CI never has (lesson #5221). `retrieval_logs`
|
|
and `retrieval_judgments` are indexed on `source`. `rule_usage_events` is not,
|
|
so its delete is also bounded by `created_at` (indexed): the arm shipped with
|
|
milestone 409 step 4, decided 2026-09-14, so no row of it predates
|
|
`ARM_BORN`, and the scan covers weeks rather than the table's whole history.
|
|
|
|
Not reversible: the arm is not coming back, so neither are its rows.
|
|
"""
|
|
from alembic import op
|
|
|
|
revision = "0121"
|
|
down_revision = "0120"
|
|
branch_labels = None
|
|
depends_on = None
|
|
|
|
SOURCE = "report_preference"
|
|
# A safe floor under the arm's first row (it shipped after 2026-09-14).
|
|
ARM_BORN = "2026-09-01"
|
|
|
|
|
|
def upgrade() -> None:
|
|
op.execute(f"DELETE FROM retrieval_logs WHERE source = '{SOURCE}'")
|
|
op.execute(f"DELETE FROM retrieval_judgments WHERE source = '{SOURCE}'")
|
|
op.execute(
|
|
f"DELETE FROM rule_usage_events WHERE created_at >= '{ARM_BORN}' "
|
|
f"AND source = '{SOURCE}'"
|
|
)
|
|
op.execute(f"DELETE FROM retrieval_tuning_events WHERE surface = '{SOURCE}'")
|
|
op.execute(
|
|
"DELETE FROM settings WHERE key IN "
|
|
"('kb_reportpref_threshold', 'kb_reportpref_top_k')"
|
|
)
|
|
|
|
|
|
def downgrade() -> None:
|
|
pass
|