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](../feedback/README.md). 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: deployed and all three schedules enabled on 2026-09-27 under the
founder's explicit scoped exception, State Hub decision
`e5dd02cb-b5b2-45c8-a600-748ea2ffd31b` (`ADMINISTER @ realm:kubernetes/railiance01`,
`activation=APPROVED`). This is not a standing waiver of the estate deployment gate.

[Setup evidence](evidence/2026-09-27-activity-core-setup.json) records the tests,
image and preflight. [Activation evidence](evidence/2026-09-27-activity-core-activation.json)
records the successful worker rollout, three completed manual workflows and their
State Hub reports, active Temporal schedules without drift, and a completed
one-shot scheduled smoke at 11:28:45 UTC. That smoke was started by Temporal;
it is distinct from the first natural recurring runs, which are still ahead.

The next regular runs are September 28 at 02:00, September 29 at 03:00, and
October 1 at 09:00, respectively, in Europe/Berlin. All verified reports correctly
say `no_consumers`, zero model calls and automatic edits disabled. Reports are
stored in State Hub under the frontend-patterns topic and the event types above.

The worker overlay changes only the resolver module and registration. API/router
images remain pinned. Rollback restores `activity-core:fi-publication-20260914`
and disables these three source definitions and their ConfigMap projections,
then syncs definitions and schedules after projected files have refreshed.

To remove future exceptions, [ACTIVITY-WP-0041](../../activity-core/workplans/ACTIVITY-WP-0041-gitops-adoption.md)
owns the concrete follow-up: reconcile manifests and publish immutable registry
images; adopt activity-core into railiance01 ArgoCD with a verified resource set;
and approve standing, bounded merge/sync authority after the adoption soak.
Existing policy requires separate authorization for adoption and automation.
ArgoCD adoption alone does not remove per-change human approval. Routine releases
must pass automated tests, scoped review, deployment-health checks and rollback;
policy/access/budget changes remain monthly decisions.

The owner handoff is [ACTIVITY-WP-0040](../../activity-core/workplans/ACTIVITY-WP-0040-frontend-patterns-feedback.md).

## 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.