chore: retire legacy rectification runtime

deploy/README.md

@@ -82,15 +82,8 @@ EPAY_CONFIG_ENCRYPTION_KEY=<independent-base64-encoded-32-byte-key>
 # Online packages stay hidden by default; only explicit true enables the fallback.
 EPAY_CHAT_ENABLED=false
 
-# Conversational birth-time rectification rollout controls.
-# Keep migrations false until the ordered database gate below has passed.
+# Fixed birth-time rectification fee shown by the account UI.
 RECTIFICATION_PRICE_CREDITS=3
-RECTIFICATION_V3_CREATE_ENABLED=true
-RECTIFICATION_V3_MIGRATIONS_READY=false
-# Set only after the authenticated synthetic smoke passes on this exact image.
-RECTIFICATION_V3_SYNTHETIC_SMOKE_SHA=
-# During canary only: one canonical synthetic account UUID. Never print or log it.
-RECTIFICATION_V3_SYNTHETIC_SMOKE_USER_IDS=
 
 # Recommended multi-model catalog. The JSON references server-only keys.
 LLM_DEFAULT_MODEL_ID=deepseek-pro
@@ -202,8 +195,6 @@ After source sync and before `up`, the workflow validates `.env.staging` mode/se
 6. If the read-only checker reports a pending migration, stop app deployment and run `Migrate Staging Database` manually with the same full SHA. Migration success does not dispatch deployment.
 7. After migration succeeds, the operator must manually start `Deploy staging` from `main` with that same exact SHA, then confirm `https://staging.jyotisha.chat/api/health` reports it and private API health.
 
-After the exact-SHA deployment and migrations are verified, use the manual `Configure Staging Rectification Rollout` workflow to change new-case creation. Supply the SHA currently reported by `/api/health`; choose `public` to open all staging accounts, `smoke_only` with canonical test-account UUIDs for a canary, or `paused` to close creation. The workflow updates only the four `RECTIFICATION_V3_*` rollout variables under the shared host lock, recreates `web` and `rectification-v4-worker` with the already deployed image, and rolls back the env file if health does not match the requested audience. Do not edit or print `.env.staging` through CI logs.
-
 Application rollback uses the same workflow: manually dispatch `Deploy staging` from the `main` controller with a previous known-good full SHA that has a successful `Staging Backend Quality Gate` run, and explicitly set `allow_rollback=true`. Normal and migration-triggered deployments reject stale, divergent, or backward revisions. Rollback still consumes the selected gate run's digest manifest and is supported only during that artifact's 30-day retention window; after expiry, stop and prepare a separately reviewed republish/recovery change rather than substituting a mutable tag or assuming the old run can still be rerun. Database migrations are separate and are not rolled back by an application deployment. Restore a staging database backup before running any destructive migration rehearsal.
 
 Inspect staging without printing secrets:
@@ -385,100 +376,20 @@ Editor shows `You do not have access to this project`, use the correct Supabase
 organization account or invite the current GitHub user to project
 `vtvnfqmonbfuxmqkqdlc` before retrying.
 
-## Conversational birth-time rectification v3 rollout
+## Agentic birth-time rectification
 
-`conversational-evidence-v3` is an account-level workflow. A web-image rollout
-does not prove its database contract is present. Apply migrations before the
-web image, in this order:
+The maintained web flow uses `POST /api/rectification/agent`. It has no standalone
+rectification worker and no V3/V4 rollout selector. Apply all pending forward
+migrations before deploying the matching web image; never delete or reverse the
+historical migrations or their billing, receipt, and audit rows.
 
-1. `20260720000000_chat_delete_and_dynamic_candidate_confirmation.sql`
-2. `20260720010000_conversational_rectification_schema.sql`
-3. `20260720020000_conversational_rectification_billing.sql`
-4. `20260720030000_conversational_rectification_transitions.sql`
-5. `20260720040000_rectification_question_handoff.sql`
-6. `20260721010000_conversational_legacy_import_projection.sql`
-
-Run `cd frontend && npx supabase db push --linked` with the authorized project
-account. Verify the linked migration ledger contains all six versions. Do not
-print the database URL or any service-role credential. Then set
-`RECTIFICATION_V3_MIGRATIONS_READY=true`, keep
-`RECTIFICATION_V3_CREATE_ENABLED=true`, set
-`RECTIFICATION_V3_SYNTHETIC_SMOKE_USER_IDS` to exactly one canonical UUID for
-the synthetic account, leave `RECTIFICATION_V3_SYNTHETIC_SMOKE_SHA` empty, and
-deploy the tested Git revision. Never print, log, copy into a ticket, or return
-that UUID from health or telemetry. Creation is available only for the
-allowlisted smoke account; ordinary authenticated users can still resume and
-finish existing cases but cannot start a paid or legacy-imported case.
-
-Before the smoke, fetch `https://jyotisha.chat/api/health` and verify the full
-deployment SHA, healthy dependencies, enabled creation, ready migrations,
-`creationAudience: smoke_only`, `syntheticSmoke: pending`, and
-`readyForNewCases: false`. A missing, abbreviated, malformed, or
-previous-revision smoke SHA must remain pending. If the create flag, migration
-flag, deployment SHA, or strict UUID allowlist is invalid, creation audience
-must be `paused`, including for the smoke account.
-
-After the smoke sequence below passes, use the guarded rollout workflow to set
-`RECTIFICATION_V3_SYNTHETIC_SMOKE_SHA` to the exact deployed 40-character
-lowercase Git SHA, remove `RECTIFICATION_V3_SYNTHETIC_SMOKE_USER_IDS`, enable
-`RECTIFICATION_AGENT_V5_ENABLED=true`, disable shadow mode, set the canary to
-100 percent, and restart both the web and rectification worker containers. The
-workflow writes these selectors together so public Case creation cannot silently
-fall back to the fixed `v4_legacy` projector. Then fetch health again and verify
-all of the following against the revision that passed validation:
-
-- `deployment.gitCommit` exactly equals the tested 40-character Git SHA;
-- `rollout.conversationalRectificationV3.protocol` is
-  `conversational-evidence-v3`;
-- `newCaseCreation` and `migrations` are `enabled` and `ready`;
-- `creationAudience` is `public`;
-- `syntheticSmoke` is `matched`;
-- `readyForNewCases` is `true`;
-- ordinary health checks remain healthy. The health response must never contain
-  environment values or credentials.
-
-Using an authorized synthetic account with no real birth data, run this smoke
-sequence. A plain HTTP `200` is not substitute evidence:
-
-1. Finish onboarding without rectification. Verify an unverified reported time
-   offers current-chat consent or `先校正再询问`.
-2. Save a synthetic ordinary question and start v3. Verify one fixed fee and a
-   rich first turn containing the candidate boundary, stable/sensitive layers,
-   domain rationale, and a dated historical-event request.
-3. Answer with one explicit event, choose `都不符合`, submit one ambiguous
-   event, then a clear event. Verify the ambiguous/future facts do not score.
-4. Pause, reload, and resume from a second authenticated browser session.
-   Verify no second rectification charge.
-5. Reach a stable candidate range and verify the prior active time remains in
-   force. Confirm that no exact minute can be accepted and that rectification
-   does not write `profiles.active_birth_time`.
-6. Explicitly continue the saved ordinary question. Verify one normal
-   consultation reservation. Delete its chat and verify the account case still
-   resumes/loads.
-7. For an unfinished legacy case, verify exactly one
-   `migration_waived` import, unchanged history, and no broad-year questionnaire.
-8. Inject one transient 502. Verify byte-identical retry and stable Chinese
-   fallback, never raw browser English.
-
-Record only protocol, phase, action kind, result category, latency bucket,
-billing state, error category, and deployment SHA. Narrative, event text, birth
-data, email, user/user-case identifiers, tokens, and model prompts are forbidden
-from telemetry.
-
-### Rollback
-
-Rollback is forward-compatible and non-destructive. First set
-`RECTIFICATION_V3_CREATE_ENABLED=false`, clear
-`RECTIFICATION_V3_SYNTHETIC_SMOKE_SHA` and
-`RECTIFICATION_V3_SYNTHETIC_SMOKE_USER_IDS`, and redeploy a revision that can still
-read/resume v3. Health must report `newCaseCreation: paused`. This stops only
-new v3 starts: keep reads, resume, answer, pause, confirmation, and saved-question
-handoff available for existing cases. Never reverse or delete the v3 migrations,
-rows, turns, evidence, receipts, or legacy import links. Never point an imported
-case back to mutable legacy history. A revision in progress keeps the account's
-prior active time until its exact atomic confirmation succeeds. If no compatible
-reader is available, leave the current image serving existing cases and disable
-only creation; do not deploy an older schema consumer.
+After an exact-SHA deployment, verify `/api/health`, then use a synthetic account
+to confirm the browser calls `/api/rectification/agent`. Confirm retired unfinished
+cases do not block the Agentic
+entry, charging remains idempotent, and a previously accepted or confirmed
+profile time is not changed without an explicit current acceptance. Do not record
+birth data, narrative, account identifiers, tokens, or model prompts in smoke
+evidence.
 
 ## Common operations