[FEATURE] VNext Phase 10 — HearthBot cutover and complete Hermes retirement

[Joncallim]

Parent: #333
Execution mode: implementation
Depends on: #343, #191
Final migration rule: one workflow, one writer/authority at a time

Problem Statement

Hermes/HearthBot currently carries useful orchestration behaviors learned before VNext, but retaining Hermes as a fallback, sub-orchestrator, state bridge or compatibility layer would leave Forge without a single source of authority and make duplicate external side effects possible.

The migration must preserve useful requirements while explicitly rejecting Hermes code/config/state/runtime compatibility.

Desired Outcome

Forge becomes the sole durable orchestrator for retained agentic workflows. HearthBot may remain as a thin presentation/request/approval/notification interface, but Mission/Execution/Trigger/Resource/Grant/Budget/Artifact/Gate state is owned only by Forge/PostgreSQL. Hermes services, cron jobs, routing/state stores and Hermes-only credentials are removed after each workflow has a proven Forge-native replacement.

User Story

As the Forge operator,
I want one orchestration system with HearthBot as a convenient interface rather than a second brain,
So that scheduled work, notifications, provider routing and side effects remain deterministic, inspectable and safe after Hermes is retired.

Requirements

A. Live responsibility inventory

At implementation time, inspect the actual running environment rather than relying on old docs/memory. Produce a cutover ledger with one row per active Hermes/HearthBot responsibility:

• user-visible purpose;
• current trigger/input;
• current external side effects;
• credentials/resources used;
• current schedule/condition;
• current notification/output;
• whether still needed;
• Forge-native replacement owner (Mission/Workforce/Trigger/Adapter/etc.);
• acceptance test;
• cutover state and rollback boundary.

Drop unused/obsolete behavior deliberately; do not preserve features for parity.

B. Forbidden compatibility

Repository/runtime tests must reject or prove absence of:

• Hermes source import/dependency;
• Hermes state.db or other DB reads/writes;
• Hermes routing bridge/API as runtime fallback;
• Hermes cron prompt/config import;
• Hermes provider/delegation manifest compatibility;
• copied parent-agent prompts/state;
• Forge -> Hermes execution fallback.

Migration data may be human-reviewed requirements documentation only.

C. HearthBot thin interface

HearthBot/Telegram may provide:

• authenticated/allowlisted request submission;
• Mission/task status and concise evidence links;
• explicit approval/revocation actions exposed by Forge policy;
• actionable notifications;
• operator commands that map to typed Forge APIs/Operations.

It must not maintain a second orchestration database, independently choose provider authority, keep hidden Mission state, or write directly to external Resources when Forge owns that workflow.

Telegram identity/message text is input evidence, not hidden authority. Forge maps it to an authenticated Principal and current policy before consequential actions.

D. Native replacements

Only reimplement retained responsibilities using proven VNext components:

• provider health/failover/budget -> [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335 routing/readiness receipts;
• recurring schedules/conditions -> [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340/[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Mission + Trigger;
• notifications -> [FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342 typed notification adapter;
• ongoing technical responsibilities -> installable Workforces such as [FEATURE] VNext Phase 9 — Infrastructure Ops Workforce and persistent side-effect proof #343;
• reliability/autonomy visibility -> [FEATURE] Add reliability, autonomy, and regression reporting #191 evidence surface;
• external actions -> [FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342 typed adapters under [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 Grants/reconciliation.

E. Cutover protocol

For each retained workflow:

1. freeze its exact current owner/writer mapping;
2. implement/test Forge replacement using fixtures/read-only mode;
3. run shadow observation only where it produces no competing external write;
4. establish Forge Resource/Grant/Trigger/Mission and acceptance evidence;
5. stop/disable Hermes writer for that workflow;
6. atomically/operationally designate Forge sole writer;
7. exercise the real workflow;
8. verify output/side-effect/recovery;
9. remove Hermes-specific schedule/config/credential for that workflow when safe;
10. record cutover receipt and rollback boundary.

Rollback before final retirement may restore Hermes only after Forge writer is disabled/fenced. Never permit both simultaneously.

F. Provider/routing migration

Do not port Hermes routing implementation. Recreate only desired policies as #335 deterministic provider-neutral configuration. Compare representative provider outage/quota scenarios and ensure Forge receipts explain selection/fallback/holds.

G. Scheduled responsibility migration

Translate active cron/monitoring intent into Mission + Trigger + deterministic prefilter contracts. Prove unchanged idle windows consume zero model tokens. Do not copy cron prompts as permanent parent-agent context.

H. Notifications

Migrate only actionable notification behavior. Deduplicate/coalesce through Forge occurrence/Operation identity; do not notify on every healthy poll. Notification failure is an adapter outcome/retry/reconciliation problem, not a reason to rerun a Mission blindly.

I. Secrets/service cleanup

After each verified cutover and again at final retirement:

• stop/disable Hermes processes/services/timers/cron;
• remove startup units/config references;
• revoke/delete Hermes-only tokens/credentials where safe;
• remove obsolete provider/routing config;
• archive/remove Hermes state/config according to operator retention choice;
• ensure Forge/HearthBot secrets are scoped to their own principals only.

J. Final reboot proof

From a clean reboot/startup:

• Forge + required adapters/HearthBot start;
• no Hermes process/service/timer/cron starts;
• retained scheduled responsibilities recover correctly;
• provider/Trigger/Mission state comes from Forge;
• a representative Telegram request/status/approval/notification flow works;
• no duplicate external writer exists.

Implementation Sequence

1. Live inventory/cutover ledger — authoritative current responsibility list and explicit drop/keep decisions.
2. Thin HearthBot Forge client/auth model — status/request first, no writes beyond Forge APIs.
3. Provider/budget/readiness UI/report migration — [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335/[FEATURE] Add reliability, autonomy, and regression reporting #191 evidence, no Hermes routing bridge.
4. Schedule/conditional responsibility migration — [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340/[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341, one workflow at a time, zero-write shadow.
5. Notification adapter migration — typed/deduped actionable notifications.
6. Representative operational Mission migration — [FEATURE] VNext Phase 9 — Infrastructure Ops Workforce and persistent side-effect proof #343 as persistent proof.
7. Remaining retained workflow cutovers — each with one-writer receipt and rollback fence.
8. Hermes service/secret/config retirement — progressive, then final.
9. Repository/docs/runtime dependency purge — no operational instructions/path to Hermes.
10. Clean reboot + provider failure + scheduled-idle + notification + bounded side-effect final gate.

Primary Surfaces To Inspect First

• live system services/timers/cron and active Hermes/HearthBot config at cutover time
• Forge [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335/[FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340/[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341/[FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342/[FEATURE] VNext Phase 9 — Infrastructure Ops Workforce and persistent side-effect proof #343/[FEATURE] Add reliability, autonomy, and regression reporting #191 interfaces
• HearthBot/Telegram integration repository/config that remains in use
• Forge documentation/operator startup paths
• environment credential inventory scoped to the migration (never expose raw secrets in artifacts)

Orthogonal Checkpoints

1. Inventory completeness: compare live process/timer/cron/network/config evidence vs ledger; find orphan writers.
2. Authority: Telegram identity spoofing, stale approvals, Forge/Hermes dual-writer races, rollback fencing.
3. Schedules/idle cost: missed/duplicate trigger, unchanged window, restart and zero-token proof.
4. Provider behavior: auth/quota/rate/outage failover under Forge receipts, no Hermes fallback.
5. Notification: duplicates, failure/retry, sensitive content, irrelevant/healthy suppression.
6. Secrets/cleanup: old services/config/credentials/startup refs; no accidental deletion before verified replacement.
7. Final reboot: cold-start state reconstruction and representative end-to-end workflows.

Acceptance Criteria

• Every active Hermes-owned user-visible responsibility is explicitly retained with a Forge-native implementation/test or dropped as unnecessary.
• HearthBot submits/reads/approves through Forge without a second orchestration database or direct independent writer path.
• No production workflow has simultaneous Hermes and Forge write authority.
• Repository/runtime searches show no Forge dependency on Hermes code/config/state/API/fallback.
• Retained scheduled/monitoring workflows demonstrate zero-token idle when unchanged.
• Provider failover/budget behavior is explained entirely by Forge routing/budget/readiness evidence.
• Notifications are typed/deduped/actionable and recover independently of Mission rerun.
• Hermes services/timers/cron/startup paths are removed/disabled after verified cutover.
• Hermes-only credentials are revoked/removed where safe and recorded without leaking secret values.
• A clean reboot starts the complete required Forge/HearthBot path with Hermes absent.
• A representative Telegram request, scheduled responsibility, provider failure, approval/revocation, notification and bounded side effect all pass after reboot.
• Pre-final rollback cannot create two concurrent writers; final state has no Hermes fallback.

Out of Scope

• Bit-for-bit Hermes feature parity.
• Importing Hermes source/config/state to accelerate migration.
• Keeping Hermes as an emergency fallback after final retirement.
• Preserving token-heavy parent-agent/conversation behavior.
• New unrelated Workforces during cutover.

Implementation Scope

Very Large / operational migration - execute as many small cutover PRs/operations as there are retained responsibilities, with explicit one-writer receipts and rollback fences.

Technical Notes

This phase necessarily combines repository work with live-environment operator actions. Code can be agent-implemented; disabling services/revoking credentials must remain explicit, evidence-backed consequential operations under the operator's authority.

[github-actions]

FORGE issue validation

This Feature issue now matches the required FORGE template structure.
The validator applied ready-for-agent and removed needs-clarification if it was present.

[Joncallim]

Hostile final-cutover addendum — quiescence watermarks, in-flight effect reconciliation, and no-consumer-shadow races

A fresh migration pass found one major gap behind the otherwise correct “do not import Hermes state” rule: refusing to copy Hermes orchestration state does not by itself prevent Forge from replaying an already-handled schedule/event/notification/action after the writer switches. Phase 10 needs explicit handoff barriers derived from live/external truth, without making Hermes state a Forge dependency.

1. Every retained responsibility gets a stable cutover identity and authority epoch

The cutover ledger row is not just documentation. For each retained workflow define a stable logical responsibility id and append-only cutover epochs such as:

legacy_hermes
shadow_forge_read_only
forge_writer_pending
forge_writer_active
rollback_to_hermes (pre-final only)
retired_final

Exact vocabulary is implementation-open, but transitions are CAS/audited and one state determines which orchestrator is permitted to produce consequential intent.

The epoch binds:

• responsibility definition/revision;
• activation/cutover instant;
• allowed Trigger/input boundary;
• Forge Mission/Trigger/Resource/Grant refs;
• old writer stop evidence;
• in-flight reconciliation result;
• rollback eligibility;
• credential/service retirement evidence.

This ledger is Forge migration evidence, not an imported Hermes runtime database.

2. Freeze/drain/reconcile all legacy in-flight work before writer transfer

Before Forge becomes writer for one responsibility, prove Hermes has no ambiguous consequential work in flight.

Inventory live:

• running/queued process/job for this responsibility;
• active external request/submission if observable;
• pending approval/action;
• notification send in progress;
• scheduled event whose delivery may already have started;
• external system state/reference that can reveal a just-submitted mutation.

Preferred cutover:

1. block Hermes from creating new work for that responsibility;
2. allow known safe in-flight work to drain, or cancel it before external submission;
3. for any action that may have been submitted, reconcile against external service truth/audit before Forge action is enabled;
4. if outcome cannot be established, block the cutover or require explicit operator disposition. Do not let Forge “start fresh” and repeat it.

Hermes being stopped is not evidence that its last external request failed.

3. Establish a cutover watermark/floor from external/live facts, not Hermes orchestration state

For schedules/events/notifications, record an explicit activation boundary so Forge knows what historical inputs it may process.

Examples:

• schedule: canonical activate_from instant/first Forge schedule occurrence + catch-up policy;
• webhook/event: source occurrence/update id floor where the external protocol provides a stable sequence, otherwise cutover receipt time and source-specific replay policy;
• monitoring: last externally observed Resource version/fingerprint obtained through the new Forge reader at cutover;
• notification: outstanding finding/incident state and last externally confirmed notification reference where necessary/available.

This is new Forge initialization evidence obtained from operator/external Resource truth, not a copy of Hermes queues/state.db.

Inputs strictly before the cutover floor are not automatically replayed just because Forge has never seen them. Any intentional catch-up is bounded/explicit #341 policy.

4. Shadow mode must never steal or acknowledge single-consumer inputs

“Shadow read-only” can still break the old writer if the source has consumption semantics.

Do not shadow by:

• competing for Telegram long-poll updates with the same bot;
• acknowledging/deleting queue messages;
• advancing webhook/event offsets;
• acquiring a distributed lease that excludes Hermes;
• marking external work read/processed;
• consuming a one-shot token/callback.

For single-consumer sources use fixtures/captured/redacted replay, provider-supported mirror/fanout, read-only audit APIs, or skip live shadow and rely on canary cutover. Shadow means no competing external state change, including consumption/ack state.

5. Telegram/HearthBot handoff uses #341 occurrence identity and one consumer owner

HearthBot should be a thin authenticated interface, but Telegram delivery itself has state.

At cutover:

• exactly one live bot-update consumer/webhook owner exists;
• platform adapter authenticates the Telegram/source transport according to its supported contract;
• exact sender/chat/account allowlist maps to Forge operator Principal; message text/user-supplied names never define Principal;
• external update/callback identity maps into [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 dedupe/replay semantics;
• switching poller/webhook records a cutover update floor/watermark where available so old updates are not replayed as new Forge commands;
• no second HearthBot private queue/database becomes orchestration truth.

If the Telegram bot token is retained, re-bind it as an operator-approved #342 credential for the Forge/HearthBot adapter; do not “import Hermes credentials” by reading old Hermes config as authority.

6. Approvals/callbacks are revision-bound one-time actions

A Telegram button/message approving a consequential Forge action must bind:

• exact pending approval/Gate/Operation request identity;
• exact Artifact/plan/Resource revision;
• allowed operator Principal;
• expiry/current policy revision as required;
• one-time nonce/idempotency/replay identity.

Replayed callback or stale approval after Mission/plan/Grant/revision change is denied. HearthBot cannot convert free-form “yes” into broad standing authority.

Pending Hermes approvals are not imported as valid Forge approvals. They are explicitly expired/cancelled/re-requested through Forge after cutover if still needed.

7. Scheduled cutover has explicit pre-cutover and missed-window semantics

For every migrated cron/schedule:

• record old schedule intent as human-reviewed requirement only;
• create a new versioned [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Trigger;
• choose Forge activation instant;
• define whether any interval between Hermes stop and Forge activation uses skip | latest | bounded catch-up;
• never infer catch-up from “Hermes probably missed this”; use the documented cutover window;
• first Forge occurrence has deterministic schedule identity under the new Trigger revision;
• zero-token idle proof begins after writer activation and includes reboot/recovery.

Do not copy a cron prompt and its “last run” field into persistent model context.

8. Provider/credential migration is reconfiguration under Forge, not secret/state copying

For retained provider/service credentials:

• operator explicitly approves/creates the Forge [FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342 credential binding from the secure source/environment;
• Forge records its own credential generation/audience/scope metadata;
• Hermes config/state is not read as canonical input to generate Forge Grants/provider routing;
• where practical, rotate credential during/after migration to prove Hermes no longer possesses usable authority;
• shared credentials that cannot be rotated immediately remain a documented residual until Hermes process/config access is removed and later rotation occurs.

Never expose old/new secret values in cutover evidence.

9. Rollback is a writer-transfer operation with the same in-flight reconciliation in reverse

Pre-final rollback cannot simply “start Hermes again.”

Required:

1. fence/disable new Forge occurrences/actions for the responsibility;
2. drain or reconcile all Forge Operations/notifications/event consumption that may be in flight;
3. record a rollback watermark/external state snapshot;
4. ensure no stale Forge outbox/Trigger occurrence can wake later under the old authority epoch;
5. only then re-enable Hermes writer;
6. verify exactly one consumer/writer and expected external state.

If a Forge Operation is submission-uncertain, do not enable Hermes to issue the same logical action until the operator/reconciliation resolves the overlap risk.

After final retirement, Hermes rollback is deliberately unavailable; recovery is repair Forge, not resurrect a second orchestrator.

10. Stale Hermes processes must lose practical authority, not merely documented ownership

After each cutover, progressively remove the old writer's ability to act:

• disable service/timer/cron/job source;
• remove/revoke responsibility-specific credentials/tokens where safe;
• remove network/service endpoint access if separately configured and useful;
• remove startup/restart policy;
• ensure watchdog/container manager cannot resurrect it;
• verify process/container/socket absence.

The cutover ledger saying “Forge owns this” is not a fencing token if a stale Hermes process still has credentials and a timer.

11. Responsibility dependencies determine cutover order

Inventory must capture dependencies between responsibilities, e.g. a monitoring workflow depending on a notification channel or provider-routing view.

Build a small explicit dependency DAG/order for the migration process so Forge does not become sole writer for a workflow whose required adapter/notification/auth surface is still Hermes-owned.

Cycles must be broken by an explicit temporary non-writing/manual bridge, not by running both orchestrators as writers.

Do not preserve obsolete dependencies merely for parity; dropped responsibilities are documented and removed.

12. External side-effect continuity is evaluated per Operation/resource domain

When a retained responsibility has previously acted through Hermes, Forge starts with new Operation identities. It must nevertheless avoid duplicating externally pending/confirmed effects at the cutover boundary.

Use external Resource observation/cutover watermark to establish safe initial state. Examples:

• if an issue/notification/action already exists externally, a Forge “ensure” Operation must reconcile/adopt only when the new typed Operation contract explicitly permits adoption and exact identity matches;
• otherwise treat pre-existing state as external condition, not Forge's own successful Operation;
• never fabricate Forge provenance for a Hermes-created side effect.

Historical Hermes effects remain historical external facts, not rewritten as Forge Operation records.

13. Notification migration preserves classification and dedupe across the cutover window

A notification emitted just before Hermes stop must not be re-sent solely because Forge's notification history is empty.

For active finding/incident state, initialize Forge from the current authoritative #190/external condition at cutover and use a cutover notification floor/current finding revision. New notification Operation is sent only for an actionable transition after the admitted boundary or an explicit operator-requested catch-up.

Notification content remains classification/egress controlled; do not paste raw Hermes messages/history into Forge state as a shortcut.

14. Live inventory is multi-source and negative-proof oriented

Do not trust one ps or one config directory.

At implementation time inspect relevant supported surfaces such as:

• systemd services + timers;
• user services;
• cron/crontab/anacron where applicable;
• containers/compose/autostart;
• process tree;
• listening sockets/known endpoints;
• repository/deployment configs;
• bot/webhook ownership;
• environment/secret references without revealing values;
• external provider webhook/schedule registrations if relevant;
• startup scripts/supervisors.

Record both discovered responsibilities and searched surfaces with no finding, so “nothing left” has evidence rather than absence-by-assumption.

15. Final retirement has an archive/forensics decision before destructive cleanup

Hermes state/config is not imported into Forge, but the operator may choose to retain a sealed historical archive for rollback/forensics before final deletion.

If retained:

• treat it as historical restricted data, not runtime input;
• checksum/encrypt/access-control according to sensitivity;
• remove live credentials/secrets where safely possible or protect archive accordingly;
• Forge code/tests cannot read it as fallback.

If not retained, document deliberate destruction only after all responsibility/evidence needs are satisfied. Do not accidentally destroy the only clue to an unresolved external side effect before reconciliation.

16. Clean-reboot proof includes negative writer/consumer evidence

Beyond positive Forge workflows, final gate proves:

• no Hermes process/container/service/timer/cron/startup path;
• no Hermes bot-update/webhook consumer;
• no Hermes external writer credential known to remain active except explicitly documented non-actionable archive material;
• no Forge code/env/config references Hermes API/state/fallback;
• no stale [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 occurrence from a pre-cutover/rollback epoch can wake an obsolete responsibility;
• each retained Forge Mission/Trigger resumes from Forge PostgreSQL and correct cutover watermark;
• representative external side effect/notification remains single-instance under restart/duplicate delivery.

Reboot more than once in the final fixture if practical to prove this is not a one-boot race.

17. Hostile migration fixtures

Add/execute at minimum:

• Hermes external action times out after possible submission immediately before cutover -> cutover blocks until reconciled;
• old scheduled instant lies just before writer switch -> no duplicate Forge replay unless explicit catch-up policy;
• shadow Forge poller competes for single-consumer update -> test must demonstrate this is forbidden/avoided;
• Telegram update delivered/retried across cutover -> [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 dedupe creates one Forge request;
• stale Telegram approval callback after plan/Grant change -> denied;
• Forge action submission-uncertain during rollback request -> Hermes writer remains fenced;
• Forge stale outbox occurrence survives rollback -> authority epoch/current state prevents wake;
• Hermes watchdog/container restart tries to resurrect process after cutover -> disabled credential/startup proof prevents writer resurrection;
• notification sent just before cutover -> no duplicate from empty Forge history;
• provider credential re-bound/rotated -> Hermes loses access, Forge remains functional;
• responsibility dependency not yet migrated -> writer cutover blocked rather than dual-run;
• final reboot inventory finds an overlooked timer/socket -> phase remains incomplete.

The strengthened invariant is:

Cutover is transfer of one exact responsibility's execution authority at a known external-state watermark. Neither “Hermes stopped” nor “Forge has no old state” is enough: all in-flight effects are reconciled, all consuming inputs have a handoff floor, and rollback reverses the same fence before the other writer can act.

[Joncallim]

Architecture reconciliation — cutover remains a separately authorised operational phase

Reviewed 1 October 2026 against this issue and the existing quiescence/watermark addendum. The one-writer design is sound and substantially more complete than the original body alone. Preserve it; do not replace it with a “start Forge, stop Hermes” checklist.

Current product direction

The primary interface should be the browser-based, non-card workbench described in the #191 hand-off. HearthBot/Telegram and a supported WhatsApp adapter may remain thin alternate request/status/decision surfaces through #341/#342. None becomes a second orchestration store. A channel can be migrated independently of unrelated responsibilities only when its dependencies and sole-consumer ownership are proven.

Tighten the operational plan

1. Separate planning approval from live cutover authority. Issue review, code completion and a green fixture do not authorise disabling a live service, rebooting a host, creating/rebinding credentials, changing network/security settings or deleting archives. The implementation runbook must identify exact resources/actions and obtain the applicable operator approval at each consequential boundary. No current live host/setup task is started or resumed by this architecture hand-off.
2. Inventory is evidence, not compatibility import. Reading bounded live configuration metadata to discover responsibilities is different from feeding legacy configuration/state into Forge at runtime. Record purpose, schedule, destination, side-effect and secret-reference metadata without raw secrets, then create reviewed Forge-native definitions. No parser/bridge may silently turn the inventory into executable legacy compatibility.
3. A source watermark must obey the source's real semantics. For Telegram, do not treat one stored update ID as an eternal “all lower IDs are historical” rule: the Bot API documents changed ID behaviour after long idle periods. Bind the bot/consumer epoch and source event identity, plus the explicit cutover policy. A gap longer than the provider's retained-update window is a coverage gap, not proof that nothing happened. Official update delivery contract
4. Cutover receipts include observable coverage gaps. Record the last positively reconciled external state, stop/drain interval, first Forge observation and any unobservable interval. Skip/latest/bounded catch-up must be a deliberate per-responsibility decision. Never manufacture an exactly-once historical guarantee where the legacy writer or provider exposed no sufficient evidence.
5. Do not delete the rollback capability accidentally before its declared boundary. Archive/credential/service retirement order must match each responsibility's rollback policy. If a credential is rotated or a resource changed irreversibly, mark the exact point at which rollback becomes repair-Forge-only. “Rollback supported” must not survive after the needed credential/config is intentionally gone.
6. The migration control plane must survive what it retires. Keep the approval/status/recovery path independent of any service being stopped. If the old bot is the only communication path, establish and verify the browser/new channel first. A lost notification connection cannot silently authorise continuing the cutover.
7. Historical effects keep historical provenance. Existing external PRs/messages/service state may be observed or explicitly adopted under the typed contract; they are not backfilled as Forge-produced successes or autonomy samples. Preserve uncertainty rather than inventing continuity.

Acceptance additions

• Live action attempted with only an architecture-review request: runbook stops for the required operational authorisation.
• Long-idle Telegram source/cutover gap: no naive numeric-floor loss or fabricated complete history.
• Provider retention has elapsed: ledger shows limited coverage and the chosen catch-up/disposition.
• Credential rotation crosses the rollback boundary: UI/runbook no longer promises legacy rollback.
• Retiring the old channel cannot strand the operator without a verified replacement status/recovery path.
• Restored pre-cutover Forge backup cannot reactivate a stale writer epoch; consume [FEATURE][RELIABILITY] Add restore quarantine and external-state reconciliation for backup recovery #366's quarantine/reconciliation contract.
• Externally existing legacy result is never counted as a new Forge success.

Next step

Keep this phase last, after #343/#191 and their foundations. Prepare the responsibility ledger and approval/runbook template from requirements now; inspect the actual live environment only when implementation/cutover is explicitly commissioned. The current review changed no host, process, credential, schedule, archive, permission or issue state.