frontend-patterns/workplans/FEP-WP-0008-use-driven-improvement.md

---
id: FEP-WP-0008
type: workplan
title: "Close the ecosystem reuse and improvement loop"
domain: infotech
repo: frontend-patterns
status: blocked
lane: blue
owner: codex
topic_slug: canon
created: "2026-09-27"
updated: "2026-09-27"
state_hub_workstream_id: "9f719719-ed4e-5c57-a62f-855fe1876e17"
---

# Close the ecosystem reuse and improvement loop

User-requested 2026-09-27: make frontend-patterns reusable and valuable across the
existing ecosystem, and turn observed use into improvement with only monthly human
progress review and signoff for decisions changing the loop. Reviewed against
frontend-patterns `88fee7c` and local reuse-surface/activity-core/Glas/rein contracts.
[Operating design](../docs/ReuseAndImprovementLoop.md) is the implementation contract.

Exactly three delivery actions. Implementation has started with the local discovery entry; background
reporting is enabled; automatic pattern-editing execution is not enabled. Existing M1/M2/M3 evidence gates remain intact. Qualified
reference consumption and use-driven research may proceed before those gates under
the user's instruction. This is not a request for another up-front approval round.

## Publish and connect the reusable reference

```task
id: FEP-WP-0008-T01
status: wait
priority: high
lane: blue
state_hub_task_id: "453fc06b-be70-5913-a816-161cabe9a0a1"
```

One capability entry and index for `capability.infotech.frontend-pattern-language`,
pointing to START.md, the versioned JSON/catalog and two core sequences. Keep the
reference informational, hypotheses explicit, and consumer reliability unknown.
Verify schema/index consistency, stable raw publication and hosted federation discovery.
Use existing owner credential routing if registration requires access; never request
or copy tokens in work records.

Before modifying current research profiles, separate old preview validation from live
profile/classification state: read its pinned inputs from Git, validate current research
separately. Add immutable version selection/current pointer and test that a later
candidate/profile change neither rewrites nor breaks validation of the old release.

Integrate one short query/read/cite/record instruction through the common consumer
template owner, first in one eligible real frontend repository. Select by actual task
need, not an invented demo. Correctly retrieve a supported context and abstain on an
unsupported one. Add a contrasting consumer when actual work supplies it.

Done: published/discoverable reference plus first real pinned decision note, and frozen
release validation survives legitimate new research. Registry entry/index are prepared
in this design session; hosted registration and consumer integration remain open.

## Capture evidence of use and outcomes

```task
id: FEP-WP-0008-T02
status: wait
priority: high
lane: blue
state_hub_task_id: "49be8a8e-eaaf-5f1c-b4cd-f0c4dbac9823"
```

Implement the small receipt contract in templates/PatternUseReceipt.yaml as a versioned
schema/validator, automatic consumer closeout hook and deterministic collector. Pin
producer/source and reference revisions; record considered/selected IDs, constraints,
changed decision, applied/adapted/rejected/no-match, reported/observed outcome and evidence.
Empty IDs, delayed outcomes and unknowns are valid. Raw private content stays at source.

Use immutable events and explicit predecessor digests. Idempotent duplicate ingest,
quarantined collisions, safe relative paths/allowlisted source access and no execution
of feedback instructions. Keep fixture and real-use streams separate. Aggregate by
originating use/context, not number of comments or model runs. Reuse registry telemetry
only within its existing schema; it does not carry helpfulness evidence.

Done: at least one real use and linked outcome; positive, negative, mixed, unknown,
rejected/no-match, delayed/corrected, duplicate and malformed paths tested as fixtures.
No fabricated real outcome to close the task. Pending cases get one automated artifact
refresh after 14 days and remain unknown after 30; no manual survey dependency.

## Run bounded improvements and monthly review autonomously

```task
id: FEP-WP-0008-T03
status: wait
priority: high
lane: blue
state_hub_task_id: "f823587c-727d-515a-974d-401719420ce5"
```

Implement deterministic signal grouping/priorities and one bounded weekly investigation,
using existing learning cycles, llm-connect and a separate model review context. Connect
activity-core scheduling to a verified rein/Glas profile with scoped repository grants;
prove an executing worker, not just generated tasks. Enforce aggregate time/call/token
budgets before enabling. No unrestricted legacy fallback or self-expanding permissions.

Publish reversible qualified corrections only after source/reproduction checks, regression
and abstention cases, model review and reference validation. Preserve prior versions and
verify published readback. Keep low evidence/inconclusive outcomes rather than force an
edit. Canonical/maturity/schema policy decisions wait in the monthly packet; human
validation remains an evidence label, not a routine workflow prerequisite.

Daily intake, Tuesday weekly cycle, monthly first-day report and limits are specified in
the operating design. The first review packet is due 2026-10-01 even if activation remains
incomplete. Include outcome denominators, unknowns, meaningful changed decisions, costs,
failures and at most three policy decisions with no-response defaults. Human attention
target is one 20-minute monthly review; no routine case approval or feedback entry.

Done: one real unassisted scheduled end-to-end cycle and an automatically produced monthly
packet; duplicate delivery, restart, rejected review, denied mutation, provider failure
and rollback have recorded proofs. Prove no-data runs skip model calls and a blocked
worker still yields visible health. Where no content change is warranted, corroboration
is a valid real result; exercise publication/rollback separately with labeled fixtures.
Existing owner runtime readiness/access dependencies must be tracked here with exact
handoff references if discovered; do not ask the user to manually run each cycle.

## Acceptance and ownership

Deliver a closed chain: discover → consume → observe → investigate → verify → publish
→ revisit. A plan, registry entry, generated tasks or a cron file alone is insufficient.
Zero external consumer evidence is the starting baseline, not a measured success rate.

WP-0002 keeps seed/admission and independent-human evidence; WP-0003 keeps architectural
research and recovery assumptions; WP-0004 keeps later held-out/canonical evaluations;
WP-0006 keeps the learning ledger/comparability protocol. This plan owns instrumentation
and operational closure. Feedback-led questions take priority over another unsolicited
source-expansion cycle, except corrections needed to keep existing reference truthful.

Before finishing, hand unresolved operating issues to live records with
`origin: residual` and `origin_ref: FEP-WP-0008`; preserve empirical owners above.

## Design establishment — 2026-09-27

State Hub decision `a4d295ae-eeaf-4492-bfe0-feac6815a7b8` records the operating
design under the user mandate, not runtime activation or independent human validation.
Local capability entry passes reuse-surface validation; reference, evolution and
classification checks pass, and changed Markdown links/whitespace were checked.
The receipt template is a draft contract; its executable schema/collector belong to T02.

## Activity-core setup — 2026-09-27

Domain-owned daily/weekly/monthly definitions and the empty consumer roster are
prepared. ACTIVITY-WP-0040 owns the tested read-only collector, worker overlay and
projected definitions. See [runtime status](../docs/ActivityCoreLoop.md). Definitions
remain disabled pending the estate deployment path and live sink verification.
GLAS-WP-0012 / HFACT-WP-0001 own the unverified execution profile; no fallback is
enabled. T02/T03 remain in progress: prepared schedules and reports do not satisfy
the real-consumer, admitted execution or publication acceptance criteria.

## Reporting activated — 2026-09-27

The founder approved the scoped direct deployment exception (decision
`e5dd02cb-b5b2-45c8-a600-748ea2ffd31b`). Three report sinks passed manual production
checks; all three Temporal schedules are active, with no drift; the daily
one-shot scheduled smoke completed and posted report
`c5446c0a-125b-4703-b964-006aaef46241`. First natural cadence observations remain
pending. [Evidence](../docs/evidence/2026-09-27-activity-core-activation.json).
ACTIVITY-WP-0041 is the live follow-up for eliminating deployment exceptions
through GitOps adoption and standing bounded release authority. The reference
still has zero enrolled consumers, and no pattern-editing executor is enabled.
T01/T02/T03 stay in progress against their original end-to-end acceptance.

## Deployment exception follow-up implemented — 2026-09-27

ACTIVITY-WP-0041-T01 is complete: tested CI publication, pinned frontend projection,
registry digest deployment and readback. RPF-WP-0048-T01 adopted nine runtime
resources into scoped ArgoCD. All deployments are ready, all three definitions
remain enabled, and the post-release scheduled smoke passed. See
[release evidence](../docs/evidence/2026-09-27-activity-core-gitops.json).

Healthy observation runs from 2026-09-27T13:38:21Z for at least 24 hours. Automated
sync remains off; authenticated receipt/identity and failed-health rollback proof
remain in ACTIVITY-WP-0041-T03. Digest-aware registry retention is tracked by
RPF-WP-0048-T03; current baseline tags are protected. Reporting is operational;
consumer enrollment and admitted pattern-editing execution remain unfinished.

## Closeout audit — 2026-09-27

Local frozen-publication prerequisite in T01 is complete: [release registry](../reference/releases.json),
explicit version selection and Git-pinned corpus/package reads isolate old exports
from legitimate current-research edits. Regression tests exercise current research
changing independently, stale live profiles and altered published artifacts.

Workplan blocked; T01/T02/T03 wait on their end-to-end dependencies. T01 needs hosted
discovery and common-template-owner integration into an actual eligible frontend task,
including its first pinned decision note. T02 needs the producer closeout hook and
real use plus linked outcome; activity-core owns the existing executable event validator
and deterministic collector. The roster is still empty. Do not invent a demo consumer
or copy its fixtures into the real stream. Reopen these tasks when an eligible actual
consumer and the template integration are available.

T03 needs an admitted, budget-enforced pattern-edit executor (GLAS-WP-0012 /
HFACT-WP-0001), authenticated standing release/rollback proof (ACTIVITY-WP-0041 T03),
and a real unassisted cycle with monthly packet. Reporting and collection are already
operational; their three schedules remain enabled. The first monthly packet remains
due October 1; missing consumer/executor evidence must be reported as such. This audit
does not disable schedules or conflate the reporting worker with mutation authority.
Existing owner work records retain all dependencies; no replacement workplan is opened.