✨🧑‍💻 - Complete relative recurrence lifecycle and protected calendar after the execution checkpoint #23

# Relative recurrence lifecycle and protected calendar

- Status: Draft
- Date: 2026-11-03
- Catalog capability ID: recurrence-calendar
- Owners: Domus maintainer; engineering and product reviewers
- Related issue: https://github.com/vypdev/domus/issues/23
- New companion: specs/recurrence-lifecycle-calendar.md
- Required gates: product UX, architecture, testing, documentation, security/operations
- Open product decisions: none; proposed engineering bounds below require implementation evidence.

Retain the complete original recurrence owner, execution foundation and storage continuation verbatim. Their 37 original, 52 execution and four additional storage cases remain required: 93 counted cases, with integration aliases retained without recounting. This companion replaces none. UI, HA, both deployments, isolated Stable/Edge and every other domain remain required for the first usable product. Native SDD publication and the exact Action-managed branch are prerequisites to implementation.

## 1. Executive summary

Finish actual relative task production, durable lifecycle consumption, mixed-rule maintenance, reviewed schedule changes and truthful protected calendar facts. Preserve actual-work local-day anchoring, original command evidence and existing completed work. The calendar must distinguish planned start, due date, actual performance and approval. A successful planning/storage checkpoint does not certify these journeys.

## 2. Problem, current behavior, and evidence

Immutable development base 8b1cbc110c389b9cdb6ecd11317c95abf2c4b0a9 includes the real recurrence schema 8 merge and administration schema 9. Existing fixed materialization, finite-period expansion, pinned zone resolution, strict fixed/relative records, relative creation/planning and a fixed-only persistent runner are source facts. TaskEventFeed supplies bounded current task events; it does not implement a durable recurrence inbox or certify consumer delivery. Relative initial/successor execution, source closure/invalidation, mixed fairness, reviewed attachment/edits and the complete calendar remain unimplemented at this checkpoint.

The earlier owners preserve their dated baselines. This is a prospective continuation, not a rewrite of that history. Actual schema 9 input was captured before new DDL using the reviewed 151-module runtime, immutable genuine schema-8 input and two real profile commands with fictional HA proof. Its SQL SHA256 is e3c81ef1fa42e1ea302de60662c10e7231466ab32da1931ecde1e6d7a49213b7; independent current import and snapshot inspection pass. That input preserves two fixed slots, relative pristine progress and explicit private preferences; it is not owner HA data or relative execution acceptance. The separate administration browser PR remains separately reviewable.

## 3. Actors, surfaces, and terminology

A current authorized manager configures and reviews schedules; an authorized member reads permitted calendar facts. A composition-owned technical capability consumes configured work for one actual installation/channel/household. It never represents a performer or administrator. Operators own compatible application/data recovery. Nominal identity, source event identity, immutable completion cycle, mutable record revision, generation and observed scan position are distinct. A scan watermark is not effect proof or complete calendar freshness.

## 4. Goals

| Requirement | Behavior |
|---|---|
| RCL-01 | Materialize the real relative bootstrap and one eligible successor, including reviewed compatible attachment/adoption, without duplicate initial manual work. |
| RCL-02 | Observe bounded live and historical source facts; persist exact inbox, per-cycle closure and original successor identity; closure dominates duplicate/out-of-order work across generations and restore. |
| RCL-03 | Rejection/reopening invalidates only unstarted derived successors with retained reason/history; preserve started/completed work with review attention and no fabricated compensation. |
| RCL-04 | Fixed and relative work share one durable fair frontier and global work limits, with a separate explicit source-scan budget and both owned runtime lifetimes. |
| RCL-05 | Implement current-authorized preview/apply, pause/resume, explicit overdue skip and reschedule while retaining exceptions, started work and original recovery. |
| RCL-06 | Persist actual task-owned timing/category facts and household time defaults; project bounded protected calendar entries/counts with truthful incomplete state. |
| RCL-07 | Protect commands, cursors and original results in both deployments; preserve exact revisions and closed independent intent namespaces. |
| RCL-08 | Add required durable storage as the next genuine schema after schema 9, preserving supported inputs, canonical proof, private preferences and compatible rollback. |
| RCL-09 | Deliver and verify English/Spanish calendar journeys and HA calendar consumption under the retained owners, with Clean Architecture and complete current-source quality evidence. |

## 5. Current versus proposed product journey

| Stage | Current checkpoint | Required result |
|---|---|---|
| Configure | Relative definition and unconsumed progress | Reviewed first-work choice and actual initial obligation |
| Complete | Original task lifecycle exists | One eligible successor at the actual-work-derived date |
| Reopen | Source facts exist | Durable closure; cancellation or visible downstream review |
| Maintain | Fixed-only runner | One fair mixed-run budget with honest continuation |
| Observe | Protected task facts | Planned, due and actual calendar views with current masking |

Text equivalent: explicit authorized configuration commits its original result; bounded maintenance creates or reconciles work; current-authorized views explain actual state and remaining processing.

## 6. Functional behavior and state model

### 6.1 Production and source eligibility

Reuse shared task creation/transition rules and the existing atomic command boundary. Bootstrap creates one actual obligation from the saved initial due fact; it neither consumes a completion nor creates an ordinary manual duplicate. Reviewed attachment preserves manual work or adopts an explicitly compatible unstarted occurrence at its exact revision. Rule/generation, policy, definition, scope, progress and original source snapshots must agree inside the writer before original lookup and effect admission. Provider resolution holds no writer lock. A current or historical original preserves its exact key/result; an absent processed effect stays absent without new identities or delivery.

A successor uses original performed_at plus local calendar days in the snapshotted zone, preserving millisecond wall time for instant deadlines and dates for date-only work. Default at_completion admits current completed work pending approval; at_verification waits for current approval but never moves the derived due date. Delayed approval can expose overdue work. Keep the existing first-valid gap/whole-date, single fold appearance, finite nominal generation and policy/data fingerprints. Original actual work in the second fold remains that actual fact.

### 6.2 Durable observation and closure

Extend the semantic source boundary to classify current versus retained historical observations without weakening the existing live-only feed. Stable scoped source identity and original positions remain independent of timestamps. Page current/historical evidence deterministically, retain complete source binding and revalidate live occurrence/cycle and original eligibility at commit. Historical absent completion/approval is nonauthorizing evidence; it cannot create a successor. Persist consumed identity, cycle closure and successor relation atomically with the effect and its receipt/audit/outbox. A closed cycle stays closed even if an older completion/approval arrives after a rule edit or restored cursor.

Reopening/rejection closes the source cycle. Cancel only a still-unstarted derived successor, retaining cause, source link and history. Started/completed downstream work keeps its performance, approvals, points and stock facts; expose durable review attention instead. Do not invent a performer, approval, compensation, notification or downstream delivery. Existing manual adopted work survives restoration even when its later processed mapping is absent; do not recreate that mapping automatically.

### 6.3 Reviewed state changes

Rule states remain active, paused and retired. Pause blocks new generation while retaining assigned work. Resume previews backlog; keep_visible remains default and explicit reviewed skip preserves nominal identity, reason, actor and no award. A plan identifies retained, moved, cancelled/replaced and added slots and explicit exceptions. Current source, rule, policy and affected occurrence revisions are checked at apply, including a concurrent start. Retain compatible assignment/annotations; collisions need review. Plans never silently truncate or overwrite started/completed history. Oversized plans require an explicit smaller review, not partial application presented as complete.

## 7. User-facing configuration

Retain all original RRULE, interval, time-policy, exclusion/addition and text bounds. Only title remains mandatory for ordinary manual tasks. Existing defaults remain first_instant, next_valid_instant, at_completion, keep_visible and a 60-day horizon. No configuration widens authority.

| Input | Default | Bound and ownership |
|---|---|---|
| Horizon | 60 local days | 7..366; household timing policy snapshot |
| Run definitions and slots | 50 and 1,000 | Global across both kinds; replay and historical reconciliation consume slot work |
| Period scanning | 4,096 | Existing maximum 64,000; empty periods consume work |
| Source scanning | 4,096 rows | Proposed technical default, 1..64,000 per run; every examined row including duplicates, historical/nonactionable and lookahead consumes this separate currency |
| Source page | At most 100 rows | Respect remaining scan currency; no unbounded source lookup or cursor advance over unprocessed work |
| Preview | 300-second expiry | At most 366 days and 1,000 affected occurrences plus canonical payload bound |
| Calendar query | 31 days and 25 rows | Half-open 1..366 days, 1..100 rows; 300-second context-bound cursor |
| Week display | Monday | Private member Monday/Sunday preference with browser-neutral default |

Source/period limits are reviewed engineering controls, not human permissions or request-selected maintenance capability. A bounded source pass reports incomplete continuation when exhausted. Fixed and relative candidates consume one shared 50-definition admission window; durable admission records only actually visited definitions before provider work. Persistent source continuation and closure must survive repeated early interruption so a noisy old source cannot starve other work. Construction is inert; actual lifespans own the existing five-second polling/backoff and stop/join before storage closes. Preserve separate profile/preferences revisions; calendar display preferences must not silently change either existing closed preference/journal contract.

## 8. Clean Architecture

Pure domain owns generation/source/closure relations, timing/classification and review transitions. Application owns authorization, orchestration, fair admission, original results and bounded calendar predicates through semantic ports. Infrastructure owns canonical SQLite encoding, physical evidence, timezone/protocol adaptation and safe failure mapping. Composition alone constructs technical scope, clock, IDs, source adapters and owned workers. Presentation renders verified models and deliberate intents; it does not read SQL or grant permission.

Reuse TaskCycle completion_snapshot, actual TaskEventFeed evidence validation, current task commands and recurrence storage invariants. A provider DTO or stale event is never execution authority. Inner layers import no concrete SQL, HA, FastAPI, browser framework or timezone objects. Extend independent source inventories and executable forbidden-import fixtures for every authored runtime module; do not hide new integration logic outside coverage.

## 9. UI/UX and content contract

Provide real month/week/day/agenda views with a narrow-screen keyboard-accessible agenda, visible focus, non-color status, light/dark contrast and reduced motion. English and Spanish use stable keys, base-language matching and English fallback. Distinguish scheduled start, due-only markers, original planned time, actual performance, verification and maintenance freshness. Date-only values never acquire an invented start, duration or UTC midnight. Planned assignment filters and actual performer filters remain distinct; category is a genuine task-owned reference, not a tag alias.

Primary content states: pending explains remaining bounded processing; action required names the reviewed collision/change; blocked retains the draft and offers correction; partial identifies committed work and pending projection; complete names only the confirmed batch and its continuation. Restore explains processed historical work whose effect is absent. No earned-points, delivered-notification or empty-household claim substitutes for unavailable owning consumers.

Example text: “The task was completed on 1 January. Its next due date is 31 January. Approval is pending.” A late approval does not change the latter date. Show relevant member/source identity and one explicit next action, with safe technical detail progressively disclosed. Render untrusted names/reasons as inert text. Actual agent Chrome testing is separate from required human UX evidence.

HA calendar export consumes the same authorized projection and stable entry identity, preserves nominal/resolved policy and marks unavailable data honestly. External synchronization stays disabled initially. The existing gateway remains untouched. These retained HA cases need actual companion-adapter acceptance before feature completion; declare its actual integration/test paths before implementation rather than inventing a functioning adapter from a fixture.

## 10. Failure, recovery, and cleanup

Rollback task, source progress, closure, original receipts, audit and outbox together on precommit failure. A committed batch resumes from durable facts after crash. Restoration retains later processed evidence without reinstating its absent effects. Current and historical proof disagreement is a bounded conflict, not an initializer. Corrupt input fails closed without coercion, silent truncation or source repair. Lock/source failure produces safe attention and bounded continuation; scope denial remains fatal.

The original command key/payload/revisions remain unchanged after response loss. Current authority precedes original-result disclosure. A stale plan requires explicit refresh and review; no automatic fresh-key replacement or POST retry. Preserve a safe same-context draft; retire private data after changed verified context or logout. Cleanup only owned producers after keeping exact current/rollback application/data and necessary diagnostics.

## 11. Security, permissions, and privacy

Both actual deployment entrypoints retain current HA proof, local membership, Origin, session CSRF, expected context and strict bounded DTOs. Request data never selects the technical actor, installation or channel. Original recovery maps each action explicitly and rechecks current grants before returning private facts. Calendar ranges, filters and cursor principal/scope/expiry are closed and validated; cursors are not authentication. Outage reads retain only the original expiry and current local masking; all changes remain blocked.

Use an explicitly closed recurrence-intent namespace with exact keys, payloads and lossless int64 revisions. Preserve both existing entry and administration journal schemas; no cross-decoding or token/CSRF persistence. Bound the new intent namespace to eight records, 65,536 UTF-8 bytes and one hour without automatic expiry renewal; test corrupt, expired and foreign records. Calendar display choices use a separate owner-private record and original-action namespace, even for administrators. Migration and deliberate member creation write explicit Monday defaults at independent revision 1; reads never initialize or repair a missing/corrupt record. Existing locale and summary records stay independent. Logs, events and projections omit credentials, raw provider payloads and private preferences; only safe operation/source identifiers and state summaries are exposed.

## 12. Observability and operational UX

Expose confirmed created/replayed/historical-absent outcomes, admitted definition identities, consumed period/source budgets, last committed positions, source eligibility, durable review attention and truthful incomplete range state. Distinguish selection, scanning, effects and actual projection completeness. A process-local last-run result or delivery acknowledgement is not durable calendar freshness. Shared entry/count predicates count event kinds and distinct occurrences accurately. Source metadata and presentation labels do not authenticate anyone.

## 13. Compatibility, migration, rollout, and rollback

Preserve schemas1..8 and their immutable fixtures. Capture and publish the genuine supported schema-9 fixture before adding durable inbox/closure/attention/plan data as actual schema 10. Do not edit a version number to reinterpret an unknown layout. Normal operations reject an old supported source until explicit atomic initialization; failed migration preserves original rows/version. Validate canonical tagged data and scope/generation/original-proof relations on direct reads and independent snapshot inspection.

The genuine schema-9 input retains old recurrence and profile/privacy facts. Current schema-9 images must refuse schema 10 without mutation, and rollback selects the compatible complete image/database/generation pair. Restore keeps later original processing history, including closure, without authorizing absent work. Both actual architectures and persistent deployment lifetimes require current-source upgrade/refusal/rollback checks. Stable/Edge remain isolated; no automatic promotion or owner HA update is implied. The Edge.7 administration UI was separately installed and tested on the owner's HA; those observations do not certify recurrence, migration or calendar acceptance.

## 14. Testing strategy and numeric budget

All 93 retained counted cases and integration aliases remain mandatory in their original owners. The following 18 technical refinements exercise concrete new protocol/storage/combined boundaries; they replace none. One execution satisfying a refinement and an owner case still counts as one execution. These are planned assertions, not current test results or feature acceptance.

| Area | Minimum distinct cases | Behaviors/risks covered |
|---|---:|---|
| Bootstrap | 2 | Explicit technical refinements in the inventory. |
| Source protocol | 2 | Explicit technical refinements in the inventory. |
| Closure | 2 | Explicit technical refinements in the inventory. |
| Mixed fairness | 2 | Explicit technical refinements in the inventory. |
| Review plans | 2 | Explicit technical refinements in the inventory. |
| Calendar facts | 2 | Explicit technical refinements in the inventory. |
| Protected transport | 2 | Explicit technical refinements in the inventory. |
| Genuine migration | 2 | Explicit technical refinements in the inventory. |
| Visible surfaces | 2 | Explicit technical refinements in the inventory. |
| Total | 18 | Distinct refinement cases; repeated executions do not add cases. |

| Case ID | Area | Requirements | Scenario |
|---|---|---|---|
| recurrence-lifecycle-C01 | Bootstrap | RCL-01,RCL-08 | A restored relative bootstrap has a retained original but no task; a new runner preserves absence, original identities and zero additional receipt/event effects. |
| recurrence-lifecycle-C02 | Bootstrap | RCL-01,RCL-05 | A reviewed manual adoption becomes incompatible before commit; it rejects the exact stale revision without a second initial task or partial mapping. |
| recurrence-lifecycle-C03 | Source protocol | RCL-02,RCL-04 | A source page spends the final scan unit on a duplicate/nonactionable lookahead; no unread position is certified and a fresh process resumes the exact remaining work. |
| recurrence-lifecycle-C04 | Source protocol | RCL-02,RCL-07 | Current and historical rows have tied times or foreign scope; original source identity/position remains deterministic and no historical approval grants a successor. |
| recurrence-lifecycle-C05 | Closure | RCL-02,RCL-03 | A cycle closes under an old rule generation, then delayed completion/approval arrives after a rule edit and restore; durable closure prevents new work without rewriting original completion facts. |
| recurrence-lifecycle-C06 | Closure | RCL-03,RCL-08 | A downstream successor starts between invalidation planning and write; preserve its actual work, persist review attention once and invent no point/stock compensation. |
| recurrence-lifecycle-C07 | Mixed fairness | RCL-04 | Fixed/relative backlogs and replayed slots share exactly one shared limit of 50 definitions and 1,000 slots ceiling; period and source exhaustion retain separate truthful continuations. |
| recurrence-lifecycle-C08 | Mixed fairness | RCL-04,RCL-02 | Repeated interruption after individual admission and a noisy unavailable source cannot skip unvisited peers; independent restarted runtimes preserve fair durable frontier and cycle closure. |
| recurrence-lifecycle-C09 | Review plans | RCL-05,RCL-07 | A plan containing exclusions, reschedules and newly started work becomes stale; original apply cannot overwrite it, and lost-result recovery never replaces the key or payload. |
| recurrence-lifecycle-C10 | Review plans | RCL-05,RCL-08 | Individually legal affected records exceed the complete canonical plan/result byte bound; preview/apply rejects without partial cancellation or silent truncation. |
| recurrence-lifecycle-C11 | Calendar facts | RCL-06 | Combined actual category/type/status/priority/member filters paginate with the same entry/count predicate; due-only dates and actual performers retain different meanings. |
| recurrence-lifecycle-C12 | Calendar facts | RCL-06,RCL-04 | A scan watermark advances while earlier source work remains unresolved; the calendar stays incomplete and never converts that watermark into an empty complete household. |
| recurrence-lifecycle-C13 | Protected transport | RCL-07,RCL-06 | Another current administrator alters a principal-bound cursor or own calendar preference result key; both deployments reject disclosure without changing bytes or extending an outage lease. |
| recurrence-lifecycle-C14 | Protected transport | RCL-07,RCL-09 | A calendar edit above 2^53 survives actual browser wire, SQLite and original recovery exactly; corrupt/foreign recurrence intent records cannot decode as entry/admin records. |
| recurrence-lifecycle-C15 | Genuine migration | RCL-08 | The actual frozen9input upgrades atomically to schema 10 with two fixed slots, pristine relative progress, false private summaries and original evidence intact; an injected late failure preserves schema-9 bytes/version. |
| recurrence-lifecycle-C16 | Genuine migration | RCL-08,RCL-02 | A compatible restored schema-10 generation retains later cycle closure/original proofs while its successor is absent; an actual schema-9 image refuses schema 10 and no edited header is treated as rollback. |
| recurrence-lifecycle-C17 | Visible surfaces | RCL-09,RCL-06 | Actual EN/ES narrow-screen month-to-agenda keyboard navigation names planned/due/performed/approval times, retains inert reasons and shows incomplete processing independently of color. |
| recurrence-lifecycle-C18 | Visible surfaces | RCL-09,RCL-07 | Actual HA calendar retry preserves UIDs/offset policy and becomes unavailable on source failure; disabled external synchronization transmits no household records. |

Tests first, strict types, real independent SQLite writers, deterministic clocks/provider failures, crash/restore, actual HTTP, Storybook, compiled browser and actual image acceptance. Require 100% supported coverage globally and per authored module; all four frontend metrics, backend statements/branches, independent source inventories and every-PR CI Check. Do not infer semantic or human acceptance from test counts. Preserve timeout/retry/privacy gates and actual failing diagnostics.

## 15. Documentation and discoverability

| Path | Change |
|---|---|
| specs/recurrence-lifecycle-calendar.md | create |
| backend/src/domus/domain/relative_lifecycle.py | create |
| backend/src/domus/domain/calendar_values.py | create |
| backend/src/domus/application/relative_materialization.py | create |
| backend/src/domus/application/recurrence_sources.py | create |
| backend/src/domus/application/relative_lifecycle.py | create |
| backend/src/domus/application/recurrence_review.py | create |
| backend/src/domus/application/calendar_queries.py | create |
| backend/src/domus/application/calendar_commands.py | create |
| backend/src/domus/infrastructure/sqlite_relative_lifecycle.py | create |
| backend/src/domus/infrastructure/sqlite_calendar.py | create |
| backend/src/domus/entrypoints/recurrence_http.py | create |
| backend/src/domus/entrypoints/calendar_http.py | create |
| backend/src/domus/entrypoints/recurrence_dto.py | create |
| backend/src/domus/composition/calendar.py | create |
| frontend/src/domain/calendar.ts | create |
| frontend/src/application/calendar-controller.ts | create |
| frontend/src/adapters/calendar-http.ts | create |
| frontend/src/adapters/calendar-journal.ts | create |
| frontend/src/presentation/domus-calendar.ts | create |
| frontend/src/presentation/calendar-messages.ts | create |
| frontend/stories/calendar.stories.ts | create |
| tests/backend/test_relative_materialization.py | create |
| tests/backend/test_recurrence_source_observations.py | create |
| tests/backend/test_relative_lifecycle.py | create |
| tests/backend/test_sqlite_relative_lifecycle.py | create |
| tests/backend/test_mixed_recurrence.py | create |
| tests/backend/test_recurrence_review.py | create |
| tests/backend/test_calendar_values.py | create |
| tests/backend/test_calendar_queries.py | create |
| tests/backend/test_calendar_http.py | create |
| tests/backend/test_recurrence_http.py | create |
| tests/backend/test_recurrence_lifecycle_migration.py | create |
| frontend/tests/calendar-controller.test.ts | create |
| frontend/tests/calendar-http.test.ts | create |
| frontend/tests/calendar-journal.test.ts | create |
| frontend/tests/calendar-component.test.ts | create |
| frontend/tests/e2e/calendar.spec.ts | create |
| tests/fixtures/sqlite/v9.sql | create |
| tests/containers/test_relative_recurrence_image.py | create |
| tests/containers/test_calendar_image.py | create |
| docs/tasks/recurrence.md | create |
| docs/tasks/calendar.md | create |
| docs/evidence/recurrence-lifecycle-calendar.json | create |
| specs/catalog.json | update |
| specs/CATALOG.md | update |
| backend/src/domus/domain/tasks.py | update |
| backend/src/domus/domain/task_values.py | update |
| backend/src/domus/domain/relative_recurrence.py | update |
| backend/src/domus/application/ports.py | update |
| backend/src/domus/application/recurrence_ports.py | update |
| backend/src/domus/application/task_creation.py | update |
| backend/src/domus/application/task_commands.py | update |
| backend/src/domus/application/task_queries.py | update |
| backend/src/domus/application/task_events.py | update |
| backend/src/domus/application/fair_recurrence.py | update |
| backend/src/domus/application/fixed_materialization.py | update |
| backend/src/domus/application/relative_recurrence_commands.py | update |
| backend/src/domus/infrastructure/sqlite.py | update |
| backend/src/domus/infrastructure/sqlite_snapshots.py | update |
| backend/src/domus/infrastructure/sqlite_recurrence_schema.py | update |
| backend/src/domus/infrastructure/sqlite_relative_recurrence.py | update |
| backend/src/domus/infrastructure/sqlite_relative_recurrence_records.py | update |
| backend/src/domus/infrastructure/sqlite_recurrence_integrity.py | update |
| backend/src/domus/infrastructure/sqlite_tasks.py | update |
| backend/src/domus/infrastructure/recurrence_worker.py | update |
| backend/src/domus/composition/recurrence.py | update |
| backend/src/domus/composition/server.py | update |
| backend/src/domus/composition/ingress.py | update |
| frontend/src/composition/entry-page.ts | update |
| frontend/src/presentation/domus-app.ts | update |
| tests/browser/entry_server.py | update |
| tests/backend/test_openapi.py | update |
| tests/python/test_ci_contract.py | update |
| .github/workflows/ci_check.yml | update |
| architecture/python-application.ini | update |
| tests/architecture/test_python_architecture.py | update |
| docs/contracts/household-api.openapi.json | update |
| docs/contracts/native-household-api.openapi.json | update |
| docs/architecture-recurrence.md | update |
| docs/tasks/execution.md | update |
| docs/tasks/migration.md | update |
| docs/development.md | update |
| docs/operations.md | update |
| docs/user-guide.md | update |
| docs/acceptance-plan.md | update |
| docs/roadmap.md | update |
| specs/recurrence-calendar.md | reference |
| specs/recurrence-execution-foundation.md | reference |
| specs/recurrence-storage-continuation.md | reference |
| specs/household-tasks.md | reference |
| specs/task-execution-foundation.md | reference |
| specs/household-administration.md | reference |
| docs/contracts/home-assistant.md | reference |
| addon-edge/config.yaml | reference |

Operations are relative to the verified immutable development base. Each create path is new; update/reference paths exist there. Register this companion under the existing capability and preserve every owner byte. Declare additional actual source/test paths before their implementation. Document normal paths, current authorization, configuration precedence, pending/absent/unavailable states, original recovery, both deployments and compatible operator rollback. Evidence records exact source, commands, artifact identity, results and limits without relabeling earlier checkpoints.

## 16. Acceptance

1. Given the saved unconsumed relative rule, when real bounded maintenance runs, then one initial obligation or its retained historical absence is observed with exact original proof.
2. Given late verification or out-of-order reopening across generations, when source consumption resumes, then actual-work dates and durable closure determine the one permitted successor effect.
3. Given unstarted and started downstream work, when the source is rejected/reopened, then only unstarted work is invalidated and preserved work has durable review attention.
4. Given mixed backlogs, interruption and limited scan currencies, when both actual runtimes restart, then shared work bounds/fairness and incomplete facts remain truthful.
5. Given current previews and concurrent changes, when apply/recovery runs, then explicit exceptions/history and original revisions survive without new-key duplication.
6. Given protected paged calendar and own preferences, when either deployment reads/changes data, then current grants, exact scope/revisions and actual predicates protect every fact.
7. Given the genuine schema-9 input or compatible schema-10 restore, when migration/refusal/recovery runs, then profile/recurrence/original facts persist and absent effects are not recreated.
8. Given real localized UI and HA calendar adapters, when users navigate or providers fail, then meaningful accessible states, stable identities and honest unavailability match the owning cases.

These acceptance scenarios and every retained case require actual observable evidence before closure. No native proposal, stored fixture, simulator or agent approval substitutes for required human UX or owner deployment acceptance.

## 17. Requirements traceability

| Requirement | Cases |
|---|---|
| RCL-01 | recurrence-lifecycle-C01, recurrence-lifecycle-C02 |
| RCL-02 | recurrence-lifecycle-C03, recurrence-lifecycle-C04, recurrence-lifecycle-C05, recurrence-lifecycle-C08, recurrence-lifecycle-C16 |
| RCL-03 | recurrence-lifecycle-C05, recurrence-lifecycle-C06 |
| RCL-04 | recurrence-lifecycle-C03, recurrence-lifecycle-C07, recurrence-lifecycle-C08, recurrence-lifecycle-C12 |
| RCL-05 | recurrence-lifecycle-C02, recurrence-lifecycle-C09, recurrence-lifecycle-C10 |
| RCL-06 | recurrence-lifecycle-C11, recurrence-lifecycle-C12, recurrence-lifecycle-C13, recurrence-lifecycle-C17 |
| RCL-07 | recurrence-lifecycle-C04, recurrence-lifecycle-C09, recurrence-lifecycle-C13, recurrence-lifecycle-C14, recurrence-lifecycle-C18 |
| RCL-08 | recurrence-lifecycle-C01, recurrence-lifecycle-C06, recurrence-lifecycle-C10, recurrence-lifecycle-C15, recurrence-lifecycle-C16 |
| RCL-09 | recurrence-lifecycle-C14, recurrence-lifecycle-C17, recurrence-lifecycle-C18 |

Retained original mappings stay unchanged. The new reciprocal table covers only the 18 technical refinements; it neither recounts nor certifies the 93 retained cases.

## 18. Implementation sequence

1. Obtain native publication/exact branch and verify actual schema-9 base/owner/path inventories. Publish the captured immutable schema-9 fixture before new DDL.
2. Tests first for source observations, closure/generation binding and atomic relative bootstrap/successor effects; add schema 10 and independent corruption/migration controls.
3. Integrate fair mixed budgets and both owned lifetimes, then reviewed attachments/exceptions and exact original recovery.
4. Implement actual task timing/category/defaults, bounded calendar predicates and both protected entrypoints.
5. Deliver localized accessible UI and retained HA projections with actual adapter/browser/image acceptance; keep all-domain launch scope.
6. Run complete current-source quality/review, audit every retained case and actual human UX, document operator recovery and clean owned temporary artifacts.

## 19. Definition of Done

- [ ] All 93 retained cases, integration aliases and 18 technical refinements have scoped truthful evidence without double-counted executions.
- [ ] Relative source/effect/closure, mixed fairness, preview and calendar behavior agree under current authority, restart and restore.
- [ ] Genuine schema-9 migration, next-schema refusal and complete compatible rollback are verified on both actual architectures/deployments.
- [ ] Clean Architecture, independent inventories, strict types and 100% supported global/per-module coverage pass with every-PR CI Check.
- [ ] No unresolved Bugbot finding remains; separate Copilot errors are reported without changing its source, bounds or acceptance.
- [ ] Real EN/ES UI, HA calendar, required human UX and owner acceptance remain distinct and complete before claiming full capability/release readiness.
- [ ] Documentation/catalog and original-operation privacy are current; necessary input/evidence/rollback are retained and owned unused producers removed.

## 20. References and decisions

The unchanged original recurrence owner, execution foundation and storage continuation are normative references listed in section15. Existing product decisions remain authoritative. Proposed source-scan limits and data/port decomposition are engineering decisions, not invented owner answers. The actual development merge and genuine schema 9 input establish source provenance only. Use the original byte-verified SDK for ownership, format, derived budgets, reciprocal mappings and path validation; the Action owns publication and branch lifecycle. The local companion proposal alone establishes no implementation or product acceptance.