frontend-patterns/docs/ActivityCoreLoop.md

Activity-core receipt loop

FEP-WP-0008 owns this integration. The initial delivery is deterministic collection and reporting. Automatic investigation and publication are a separate, outstanding execution dependency; a weekly report is not evidence of an improvement cycle.

Definition	Europe/Berlin schedule	Output event
frontend-patterns-daily	Daily 02:00	fep_feedback_intake
frontend-patterns-weekly	Tuesday 03:00	fep_improvement_review
frontend-patterns-monthly	First day 09:00	fep_monthly_review

Definitions live in activity-definitions/. Activity-core projects the identical Markdown into its external-definition ConfigMap. Its frontend-patterns context resolver reads this repository's feedback/sources.json at a resolved commit, then reads enrolled consumer indexes and receipts at resolved commits. See the enrollment contract. Initially the roster is empty; reports must say no_consumers, never imply measured usefulness or coverage.

The collector validates identities, hashes, chronology, decisions and evidence presence, reduces immutable event chains to one observation per use, and quarantines ambiguous chains. Synthetic outcomes have separate counts. Outcomes remain producer assertions until investigation verifies their evidence. Missing or malformed sources produce a degraded report. Monthly reports cover the previous calendar month in Europe/Berlin, using observations available before its end. They are receipt summaries, not yet the complete cost/decision review packet.

Collection allows ten repositories, 100 events per run, 128 KiB per source file and a 45-second fetch deadline (an in-flight read may finish up to five seconds later). Over-limit sources are reported as errors; durable pagination is still required before expanding enrollment. Only the fixed Forgejo host and validated relative paths are read. No secret retrieval, shell execution, LLM calls or repository mutation is performed. Required context prevents an absent resolver from silently producing a successful empty report.

Activation and proof

Current state: source definitions are disabled; collector and deployment are prepared under ACTIVITY-WP-0040. No scheduled production execution is claimed. The worker overlay changes only the resolver module and registration, based on the existing production worker image. API, router and dependencies stay pinned.

Activation requires the documented cluster change path. The estate's the-custodian/docs/kubernetes-change-gate-decision.md treats unmapped targets as production-tier and requires Git/ArgoCD reconciliation. Activity-core currently has no ArgoCD application. A direct rollout therefore needs an explicit scoped policy exception, or prior ArgoCD adoption; ordinary permission to implement is not a claim that the estate gate has already been satisfied.

Once deployed, sync definitions, run one manual smoke per definition, verify the State Hub report sink, enable and re-project the definitions, then sync schedules. Record workflow IDs, schedule state and first natural scheduled executions here. Use manual smoke evidence only as manual evidence. Rollback restores the previous worker image and disables these three definitions followed by schedule sync.

The owner handoff is ACTIVITY-WP-0040.

Unattended improvement remains open

GLAS-WP-0012 and HFACT-WP-0001 own the missing admitted executor proof. The available development profile is operationally unverified and does not enforce the loop's llm-connect budget (six calls / 40,000 aggregate tokens / 30 minutes). Do not emit unexecutable work or fall back to an unrestricted legacy worker. WP-0008-T03 retains the end-to-end execution, independent review, publication and rollback proofs. WP-0008-T01/T02 retain first real consumer integration, frozen release validation, producer closeout hooks and delayed-outcome refresh. These are live tasks, not implied completions of this reporting foundation.