[M2/P1] Implement scheduled source acquisition—or formally defer it

[samovers]

Parent: #167
Depends on: #171, #172, #173, #175, #178, #185
Country-provider consumers: #159 and later #162

Problem

M2 documentation can be read as claiming scheduled reference refresh, while the executable adapters currently declare cadence but do not provide a scheduler/cron runner. A declared interval is configuration, not execution evidence.

Leaving the distinction implicit creates two risks:

• operators may believe reference state refreshes automatically when only manual/test invocation exists;
• a later country adapter may smuggle scheduling, raw storage mutation, or truth/currentness claims into provider code.

Required decision

Choose and record exactly one bounded posture before implementation:

A — implement scheduling

Build a provider-independent acquisition orchestrator outside the Kernel domain core. It triggers the governed import command from #185 and treats provider code only as source acquisition/translation.

B — explicitly defer scheduling

Narrow M2 documentation and status to “governed import mechanism with explicit/manual/injected trigger.” Remove or qualify every statement that implies scheduled execution, and open one parked implementation follow-up with a named deployment gate.

Codex must not infer A or B from this ticket. The decision is a small reviewable artifact. If no product/deployment requirement currently needs autonomous refresh, B is the default conservative posture.

Acceptance criteria for posture A

• Scheduling runs outside the Kernel transaction/domain core and calls the public governed command from [M2/P0] Add governed commands for bindings, extents, verification, and reference imports #185; no scheduler path writes stores directly.
• Job identity is exact over tenant, provider, source family, configuration version, and intended vintage/window.
• A trusted service Party authenticates explicitly and proves the narrow action authority required by [M1/Security] Enforce the Authority Action Matrix through a governed control plane #175.
• Durable leases or equivalent coordination guarantee deterministic at-most-one accepted acquisition/import result across multiple workers while safe retries remain possible.
• Define cadence, jitter, retry/backoff, timeout, missed-run/catch-up policy, manual-trigger floor, pause/resume, and configuration-revision semantics.
• Every attempt records immutable start/end, trigger, worker/lease identity, RuntimeBundle, source request identity, preserved artifact digest, parser identity, result/refusal, and links to any ReferenceSnapshot.
• Download success, parse success, import success, currentness, authority, and capability are distinct states. None implies the next.
• Partial download, timeout, malformed source, duplicate trigger, overlapping run, revoked authority, crash before/after import, and shutdown recover without partial accepted state.
• Operator status is observable and tenant-scoped but does not make a capability/current-compliance claim.
• Tests use fake clocks/providers and cover multi-worker contention, duplicate delivery, retry, backoff, missed cadence, crash recovery, configuration change, stale response, and graceful shutdown.

Acceptance criteria for posture B

• Inventory and correct every M2 status/readiness/documentation surface that says or strongly implies “scheduled,” “automatic refresh,” or equivalent.
• State the actual trigger surface and operator responsibility precisely.
• Existing generated manifests and ActiveArtifactSets remain untouched. If one currently claims scheduler execution, stop and route the discrepancy through [M1/Truth] Ground capability reporting in exact code and executed evidence #183 rather than hand-editing it.
• Open a parked scheduler implementation issue with explicit prerequisites: [M2/P0] Add governed commands for bindings, extents, verification, and reference imports #185 complete, deployment topology selected, service-principal/authority model proven, and source-specific cadence/currentness evidence available.
• Tests ensure readiness/capability reporting cannot infer a scheduler from cadence metadata, adapter presence, schema presence, or a manually executed import.

Shared boundaries

• No live external-network test or real credential.
• No country-specific source, Serbia implementation, legal currentness value, or compliance claim.
• No cron/thread/process embedded in Kernel request handling.
• No law, canonical/extracted contract, schema, manifest, ActiveArtifactSet, profile activation, or affirmative capability-claim change.
• No M3/M4/PWA work; M3.x/M4.0: Operational Action Surface descriptor layer #153-Backlog plan: Reconnect OFARM2 app surfaces to canonical Layer 6 archetypes/templates/interaction specs #156 remain parked.
• No treating a successful run as proof that the imported source is legally authoritative or current.

Validation

For posture A, run focused scheduler tests plus the full Kernel suite. For posture B, run documentation/status consistency checks and the reporting tests owned by #183. In either case run:

python3 -m kernel.manifest --verify-generated
git diff --check

Report any unrun validation honestly.

Codex stop conditions

Stop and report if the selected posture requires inventing deployment topology, credentials, cadence/currentness rules, country law, provider-owned storage writes, or any runtime/capability claim beyond available evidence.

[samovers]

Tracker-only disposition: this issue is blocked and needs a decision because it currently contains mutually exclusive outcomes. No implementation PR should open while both posture A and posture B remain live.\n\nWhat is next: select A or B. Posture B can be rewritten as one documentation/reporting Delivery issue; posture A must first be checked for scheduler, service-authority, and durable-coordination boundaries and split into a Tracking Epic if those are independently reviewable.

[samovers]

Current-main evidence check

The decision is still real. The adapters declare cadence, but the repository does not contain a provider-independent scheduler or acquisition orchestrator. The REGSR adapter explicitly says its cadence is declared but not scheduled, and the conformance tests still describe the scheduler as later M2 work.

No A-or-B posture is selected by this audit. The issue correctly remains blocked and needs-decision. If there is still no product or deployment requirement for autonomous refresh when this becomes active, posture B remains the conservative recommendation; that choice still belongs to the user.

What is next: decide A or B only after #185 is decomposed far enough to expose the real governed import interface and deployment need.