coulomb/frontend-patterns
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Establish ecosystem reuse and monthly-supervised improvement loop

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e241-8285-7a63-8c0c-51c9cb824dc3
This commit is contained in:
tegwick 2026-09-27 12:47:39 +02:00
parent 88fee7c567
commit 0da4701bd0
10 changed files with 572 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

13
AGENTS.md
View file

@ -266,3 +266,16 @@ whitespace; inspect new files as well as tracked diffs. See
Read `INTENT.md`, `SCOPE.md` and `REVIEW.md` for scope and maturity. Treat source
interpretations, candidate patterns and research stubs as provisional. Preserve
unrelated uncommitted work. Future validators belong to FEP-WP-0002.
## Use-driven improvement and monthly oversight
The user requested an ecosystem reuse/improvement loop on 2026-09-27, with routine
operation autonomous and one monthly human progress/decision review. Follow
`docs/ReuseAndImprovementLoop.md` and FEP-WP-0008. Prioritize closing discovery,
consumer-outcome capture and verified execution over another unprompted source study.
Do not require routine human receipt entry or approval of qualified draft corrections.
Keep independent-human validation as an honest evidence requirement; it does not block
qualified reference use. Loop policy, access/budget expansion and stronger maturity
claims go into the monthly decision packet. Continue within existing scope meanwhile.
A workplan or cron definition is not proof of an enabled, successful unattended loop.

3
README.md
View file

@ -6,6 +6,9 @@ Start with the [0.1 research preview](START.md): two decision paths, seventeen
draft hypotheses and evidence-qualified implementation mappings. Canonical admission,
independent usefulness and the M1/M2/M3 gates remain open.
For ecosystem use, see the [reuse and improvement loop](docs/ReuseAndImprovementLoop.md)
and its [three-action workplan](workplans/FEP-WP-0008-use-driven-improvement.md).
The project treats frontend architecture not as a choice among frameworks or named styles, but as the progressive resolution of recurring forces concerning:
- authority,

10
SCOPE.md
View file

@ -95,6 +95,16 @@ The [2026-09-27 scope–intent assessment](history/2026-09-27T010237+0200-scope-
records the current gaps and recommended priorities. Future assessments should
preserve that historical judgment and cite changed evidence.
## Ecosystem reuse and operational learning
The user-directed [WP-0008](workplans/FEP-WP-0008-use-driven-improvement.md) connects
qualified reference use to evidence-bearing consumer receipts and bounded autonomous
improvement. It owns discovery, instrumentation and execution integration; monthly
human review owns operating-policy decisions. The capability entry is prepared;
hosted registration, automatic collection and unattended execution remain unverified.
This operational loop can improve draft guidance without claiming M1/M2/M3 or
independent-human validation. See the [operating design](docs/ReuseAndImprovementLoop.md).
## Registration
- Repository: `frontend-patterns`

255
docs/ReuseAndImprovementLoop.md Normal file
View file

@ -0,0 +1,255 @@
# Reuse that improves the language
Operating design: 2026-09-27. Owner: frontend-patterns. Implementation:
[FEP-WP-0008](../workplans/FEP-WP-0008-use-driven-improvement.md).
User mandate: routine reuse and improvement run without human intervention; one
monthly progress review and signoff for changes to the loop's operating agreement.
This document establishes the design; it does not claim an enabled background worker.
## The two answers
Make the language useful **at the point of an actual architecture decision**. A
consumer supplies a problem and constraints and receives a small applicable pattern
configuration, alternatives, implementation mechanisms and explicit limits, all pinned
to a reference version. Find it through the ecosystem's existing reuse-surface index.
Keep Markdown for reading and the JSON reference for agents; do not build a new portal,
API, vector database or seventeen separate registry capabilities to start.
Make each use produce a small **evidence-bearing receipt** automatically. A receipt
records what was selected or rejected, what decision changed and what subsequently
happened. Those receipts select bounded research/correction work. A successful lookup,
model agreement, use count or approval emoji is not evidence that advice improved a
result. Positive, negative, mixed and unknown outcomes all remain visible.
The smallest viable loop is:
```mermaid
flowchart LR
A[Versioned reference] --> B[Consumer decision and use]
B --> C[Use receipt and later outcome]
C --> D[Bounded triage and verification]
D --> E[Reviewed correction or corroboration]
E --> A
D --> F[Monthly progress and decision packet]
```
## Three implementation actions
| Action | Smallest deliverable | Proof it works |
| --- | --- | --- |
| 1. Publish and connect | One federated capability; pinned Markdown/JSON pack; a brief common consumer instruction | Hosted discovery finds the guide from a real frontend brief; a consumer can follow a supported path and correctly abstain on an unsupported one |
| 2. Capture use and result | One versioned receipt contract, automatic consumer emission, idempotent collection | A real task has a linked use receipt and later outcome; negative and unknown fixtures survive collection without being counted as real use |
| 3. Improve and report | Daily deterministic intake, at most one weekly investigation, monthly report using existing scheduler/executor/llm-connect | An unassisted scheduled run consumes a receipt, verifies it, records a disposition, publishes a reversible qualified update when justified, and exposes failure/rollback evidence |
Do these in order. The first useful deployment needs one real consumer and one
completed loop, not fleet rollout or a canonical graph. Then add a contrasting
consumer when a relevant task occurs. A simulated negative receipt tests routing;
it does not prove negative feedback from users. No suitable live task means no
adoption evidence, not permission to manufacture a success.
## 1. Reference consumption
Capability: `capability.infotech.frontend-pattern-language`. Entry points remain
[START.md](../START.md) and [reference/0.1](../reference/0.1/README.md). Consumers:
1. Consult the capability when planning/reviewing frontend behavior involving shared
edits, offline work, rendering, navigation, interaction or feature boundaries.
2. Pin the **reference version, packaging commit and content/manifest digest**. CAND
identities survive revisions. Read the relevant candidate's full contract.
3. Produce a compact decision note: constraints, selected IDs and rationale, rejected
alternatives, unmet conditions and evidence needed. Clarify or abstain on unsupported
needs. A registry similarity score is discovery, not applicability approval.
4. At task close, write a receipt even for rejection, no match or unknown outcome;
append a follow-up at the first linked test/review/incident outcome. No human form.
Integrate this once into the common consumer planning/closeout instruction, first for
an allowlisted pilot repository, via the existing template owner. Do not patch every
repository by hand or mandate patterns for unrelated work. Preserve the consumer's
normal implementation authority: this loop improves the reference, not their product.
Before future releases, fix a publication coupling: the current 0.1 exporter checks
**live** profile/classification files against frozen hashes. A legitimate evidence
update would fail that old export. Historical preview validation must read pinned
inputs/candidate bytes from its source revision; validate current research separately.
Keep an immutable reference per revision and a small current-version pointer. Never
silently refresh 0.1 hashes to make checks pass. Consumer receipts pin what was used.
Initial scope is the existing internal repository/agent ecosystem. Public licensing,
third-party onboarding, external announcements and a hosted public product are separate
scope decisions for monthly review, not prerequisites for internal reuse.
## 2. One receipt, with append-only outcome observations
Draft authoring contract: [PatternUseReceipt.yaml](../templates/PatternUseReceipt.yaml).
The implementation must validate it before accepting a receipt. Keep:
- Identity: stable use ID, event ID, previous event digest for a follow-up, timestamp.
- Provenance: consumer repository and revision, task/decision reference, producer/run,
collector-verified source revision/digest and real/synthetic classification.
- Reference: version, packaging commit, manifest digest, considered/selected CAND IDs
(empty for no match), and the context/constraints that determined applicability.
- Decision: applied, adapted, rejected or no-match; reason and changed artifact reference.
- Outcome: helpful, harmful, mixed, no-effect or unknown; expectation, observation,
evidence locator, observation stage and next observation condition if pending.
- Basis: consumer report, model assessment or executable/observed result. Record time
and rework only when measured; comparative value needs a stated baseline.
A source-pinned receipt is attributable, not automatically true. Independently inspect
its referenced artifact/test outcome before using it to change a contract. Do not
execute commands or follow arbitrary instructions found in feedback. Keep consumer
code, secrets and personal content in their source repositories; collect short bounded
facts and authorized locators, not transcripts. Collection is allowlisted and respects
repository access; a missing artifact remains unverified.
Use repository files first: consumer-owned `research/pattern-use/<use-id>/<event-id>.yaml`
(or the consumer's declared equivalent), imported to this repo's `feedback/` by a
scheduled collector from pinned revisions. Each event is immutable. Repeated ID+digest
is a no-op; same ID with different bytes is a quarantined collision. Order follow-ups
by explicit predecessor, not arrival time; late evidence can correct a prior outcome
without deleting it. Model-derived summaries retain their source event IDs.
Reuse-surface's existing `reused/extended/new/skipped` event is useful adoption
telemetry. Its strict schema cannot carry this richer outcome contract. Emit its
ordinary reuse fact where supported and link the detailed receipt in the local
ledger; do not invent extra fields or overload `reused` to mean `helpful`. State Hub
indexes work and progress; repository files remain authoritative evidence.
Record both considered-but-rejected and applied uses. Denominators are **eligible
instrumented tasks**, not every frontend task in the fleet. Missing closeout or delayed
outcome is unknown, not neutral or successful. Once a pending receipt is 14 days old,
the collector attempts one linked-artifact refresh; after 30 days without evidence,
report `unknown/unobserved` without asking the human to fill it in. A later event may
still provide an outcome. Do not create recurring reminder tasks per receipt.
## 3. Triggers and the autonomous improvement rule
Daily triage groups receipts by candidate + context + failure mechanism, preserves
consumer/revision lineage and deduplicates repeated agent/model reports of one event.
The following are conservative initial routing rules, not scientific confidence levels:
| Signal | Trigger and response |
| --- | --- |
| One credible harmful result or factual counterexample | Highest priority verification; if reproduced, narrow/withdraw affected guidance and publish an advisory/erratum promptly; do not wait for positive-vote thresholds |
| Two independent uses reporting the same confusion, adaptation or missing condition | One bounded clarification investigation; independent means distinct originating tasks/evidence, not two summaries or retries |
| One helpful result with inspectable evidence | Record scoped corroboration; add a known-use example only after verifying what part of the contract was exercised |
| Repeated successful uses in different contexts | Investigate generalization and recurrence; never auto-promote from a count or a helpfulness ratio |
| Rejected/no-match guidance | Determine whether discovery wording, context limits or missing coverage caused rejection before creating another pattern |
| Zero eligible use or mostly unobserved results | Diagnose discovery/instrumentation once; show the gap monthly, do not claim lack of value or grow the corpus to compensate |
Priority is harm/counterexample, repeated friction, supported coverage gap, then
corroboration. Deduplicate into one active investigation; at most three ready items.
Unselected evidence remains in the ledger, not an expanding task fan-out. With no
qualifying signal, the scheduled research step exits successfully with `no action`.
A reference infrastructure defect can be fixed without waiting for consumer counts.
Each selected investigation:
1. Preregister one question, expected behavior, disconfirming observation, evidence
scope and budget using the existing learning-cycle method.
2. Reproduce/inspect evidence and distinguish pattern error, missing precondition,
consumer implementation error, retrieval failure and inadequate observation.
3. Keep, clarify, narrow, revise, split/merge, withdraw or mark inconclusive with reasons.
A verified success can conclude corroboration without any wording change.
4. For a change, create a regression case from the incident and test existing supported
and abstention paths. Use a separate model review context, with source evidence and
rubric, that can reject the proposed change. Identify it as model review. If another
consumer task is available, reserve it before editing as a fresh check; otherwise
claim only regression coverage, not demonstrated generalization.
5. Publish only within the autonomous scope below, after checks/review; record old/new
versions, affected IDs, receipts, tests, review and rollback target in the ledger.
Verify the pushed artifact and discovery pointer. An accepted commit alone is not
an observed publication. If review/checks fail, keep the last validated release,
record the disagreement and continue other work; do not ask for routine approval.
Counterexamples become consumed development cases after use. Do not rebrand them as
held-out tests or treat model critique as independent human validation. Keep positive
and inconclusive findings, consumer diversity, and later reversals visible.
## Autonomy agreement and monthly human role
Authorized routine scope under the user's 2026-09-27 instruction: internal discovery,
receipt collection, verification, draft-language corrections/examples/limitations,
regression tests, reversible qualified reference publication, evidence reporting and
rollback to a previously verified reference. Operate through scoped repository grants.
The loop does not modify consuming products, infrastructure permissions or its own
policy/budgets. Treat low-risk automation code repairs as changes needing their own
regression checks; policy or permission changes are monthly decisions.
Canonical admission, evidence-maturity promotion, identity merges/splits that break
consumers, changed evidence gates, new access/provider costs, broader scope and changes
to the loop's budget or policy enter the **monthly decision packet** with a recommendation,
alternatives, evidence, risk, rollback and default if unanswered. Prepare decisions
throughout the month. Continue reversible work under the existing agreement; no response
means retain the existing policy. Signoff never invents missing empirical evidence.
Historical M1/M2/M3 and independent-human gates remain open evidence claims; they do
not block qualified draft-reference use or routine improvement in this operating loop.
Initial bounded configuration to implement:
- Daily 02:00 Europe/Berlin: deterministic collection, deduplication, status and last-run
health; no LLM call when there is no new evidence. At most 100 new events per run,
cursor persisted; excess waits for the next run.
- Tuesday 03:00: at most one research cycle, one worker at a time, 30 minutes total,
at most six llm-connect calls and 40,000 aggregate input/output tokens including
reviewer calls and retries. These are new deployment limits, not claimed existing
harness guarantees. Reserve budget before calls; if the route cannot enforce the
aggregate limit or report enough usage, stop the paid phase and record the limit.
No new provider subscription or self-expanded budget. No automatic retry loop.
- First of each month 09:00: one progress/decision packet for the preceding calendar
month. Target human effort: 20 minutes and at most three decision proposals. This
is an attention budget, not an observed time saving. Default review date: 2026-10-01.
- Job failures: retain receipts/checkpoints; one scheduled retry of a transient failure,
then defer that item with evidence. Independent collection/reporting continues.
Do not catch up missed weeks by running a burst of investigations.
- Suspected damaging guidance: locally mark affected reference paths under review;
verified harm permits reverting/withdrawing only the affected qualified guidance.
Other consumers and unaffected patterns continue. Never silently erase history.
Each monthly packet contains: eligible tasks → consulted → applied/adapted/rejected →
observed outcomes; unknowns and observation lag; scoped helpful/harmful/mixed counts;
concrete decision changes or avoided rework (only if evidenced); external versus
self-generated receipts; corrections and regressions; research cost/effort; and schedule,
collection, verification, publication and rollback health. Show numerator/denominator,
context and sample size, not a single maturity/value percentage. Compare with prior
months only within comparable contexts. Include no more than three decisions, each
with a default-to-existing-policy fallback. The packet is produced even with no data
or failed workers; it must explicitly say which evidence is missing.
## Ecosystem integration and current activation gap
Reuse existing owners, verified in local source on 2026-09-27:
| Function | Existing owner/surface | Integration needed |
| --- | --- | --- |
| Discovery | reuse-surface, `capabilities.yaml`, hosted federation/plan-check | Publish/register this capability; verify matching and consumer entry |
| Use/closeout instruction | Common consumer template owner, the-custodian/repo-seed; pilot consumer agent | Select an eligible repo and add the bounded use/receipt hook through normal template rollout |
| Evidence and work | This repository; State Hub projection/progress | Receipt validation/import, grouping, versioned dispositions and monthly report |
| Timing and dispatch | activity-core cron and `ops_runs` | Definitions, typed dispatch and successful next-fire evidence |
| Execution | rein-aharness → versioned Glas profile and repository grant | Prove read/write/test/commit/publish scope, no fallback on profile failure |
| Model calls | llm-connect | Bounded author/reviewer execution and usage receipts |
The hosted reuse registry query returned no frontend-patterns registration on
2026-09-27. Existing State Hub workplans reported manual launch/execution. Local Glas
scope/profile evidence reports blocked or unverified execution profiles; activity-core
can schedule/dispatch work but does not itself execute general repository changes.
These observations are integration gaps, not evidence that a scheduler is running here.
Owner deployment state must be rechecked at activation; old local status is not a live
outage diagnosis. Existing profile failures must not be bypassed with unrestricted
legacy execution.
WP-0008 T03 owns end-to-end activation proof, including successful real unattended
execution, duplicate delivery, denied write, provider failure, restart/resume, rejected
change and rollback. Its deployment work must route dependencies to existing owners;
automatic task emission is not completion. If an access/budget policy change is actually
needed, prepare it for the monthly packet, while deterministic work proceeds. Do not
claim the user's monthly-only operating requirement met until these proofs pass.
## Basis
This is a design decision, not an empirical language-learning result. Local contracts:
reuse-surface `specs/PlanCheck.md`, `schemas/reuse-event.schema.json`,
`docs/RegistryFederation.md`; activity-core `SCOPE.md` and `docs/adr/adr-003-rule-instruction-model.md`;
rein-aharness and glas-harness `SCOPE.md`; fleet `autonomy-lanes_v0.1.md`.
The receipt distinction between a versioned artifact, an activity and its producer is
consistent with the [W3C PROV primer](https://www.w3.org/TR/prov-primer/). JSON/YAML
receipts suffice here; no RDF infrastructure is proposed or required.

76
registry/capabilities/capability.infotech.frontend-pattern-language.md Normal file
View file

@ -0,0 +1,76 @@
---
id: capability.infotech.frontend-pattern-language
name: Frontend architecture pattern reference
summary: Reason about frontend shared edits, offline recovery, navigation and rendering with versioned candidate patterns, alternatives and evidence limits.
owner: frontend-patterns
status: draft
domain: infotech
tags: [frontend, architecture, patterns, offline, mutation, recovery, navigation, rendering]
maturity:
discovery:
current: D3
target: D4
confidence: medium
rationale: Two bounded decision sequences, qualified source reviews, alternatives and explicit gaps; ecosystem usefulness remains unverified.
availability:
current: A0
target: A0
confidence: high
rationale: Informational Markdown and JSON reference; no frontend runtime or service offered.
external_evidence:
completeness:
level: C1
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations: [two core decision paths and seventeen qualified candidate records]
broken_expectations: []
out_of_scope_expectations: [complete implementation recipes and production guarantees]
reliability:
level: R0
confidence: high
basis: consumer_quality_signals
known_reliability_risks: [no measured ecosystem consumer outcomes, full-contract recurrence unassessed]
discovery:
intent: Help a consumer turn frontend constraints into a small explainable configuration and implementation questions.
includes: [transactional edit recovery, local offline work, candidate relations, mechanism mappings, stated abstention boundaries]
excludes: [complete security architecture, offline global exclusivity, framework rankings, certified production recipes]
assumptions: [consumer checks applicability and implementation contracts, draft hypotheses retain their evidence limits]
use_cases: [VC-01, VC-02]
research_memos: [research/reviews/M1-SeedReview.md, research/reviews/PreviewOntology-0.1.md]
availability:
current_level: A0
target_level: A0
current_artifacts: [START.md, reference/0.1/index.json, reference/0.1/manifest.json]
target_artifacts: []
consumption_modes: [informational, markdown, json]
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation: [START.md, reference/0.1/ReleaseReview.md, docs/ReuseAndImprovementLoop.md]
tests: [tests/test_reference_preview.py]
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for: [frontend architectural decision notes, reviewing shared-edit and offline-recovery assumptions]
not_recommended_for: [claiming canonical maturity or production guarantees, treating a match score as applicability proof]
known_limitations: [all candidates are hypotheses, no independent human usefulness result, use feedback automation not deployed]
promotion_history: []
---
# Frontend architecture pattern reference
Start at [the decision guide](../../START.md). Pin the reference version and packaging
commit, inspect the candidate contracts, and cite selected IDs and unresolved conditions
in your decision note. The [JSON export](../../reference/0.1/index.json) supports agent
navigation; it is a research candidate surface, not an admitted canonical graph.
Qualified extension hypotheses cover navigation, rendering and feature/interaction
boundaries. Their presence does not imply a complete sequence for those contexts.
The [reuse and improvement contract](../../docs/ReuseAndImprovementLoop.md) defines
how consumer decisions and later outcomes will improve this language. Receipt collection
and unattended improvement require WP-0008 implementation; do not imply that recording
`reused` in registry telemetry already measures helpfulness.

14
registry/indexes/capabilities.yaml Normal file
View file

@ -0,0 +1,14 @@
version: 1
updated: "2026-09-27"
domain: infotech
capabilities:
- id: capability.infotech.frontend-pattern-language
name: Frontend architecture pattern reference
summary: Reason about frontend shared edits, offline recovery, navigation and rendering with versioned candidate patterns, alternatives and evidence limits.
vector: D3 / A0 / C1 / R0
domain: infotech
status: draft
owner: frontend-patterns
path: registry/capabilities/capability.infotech.frontend-pattern-language.md
tags: [frontend, architecture, patterns, offline, mutation, recovery, navigation, rendering]
consumption_modes: [informational, markdown, json]

10
research/plan/ResearchProgram.md
View file

@ -362,6 +362,16 @@ ledger and task status, and commits and syncs the result. Review at every phase
and whenever contradictory evidence changes the ontology. Review roles are explicit
in the resulting review document; a self-review must be identified as such.
### User-directed operational reuse — 2026-09-27
[WP-0008](../../workplans/FEP-WP-0008-use-driven-improvement.md) establishes the
minimal discovery → use receipt → bounded improvement loop with monthly human
oversight. Qualified draft use and feedback-led research can proceed before M1/M2/M3;
those gates still control their original evidence/admission claims. Independent-human
validation remains unclaimed and is not a routine operation dependency. Prioritize
real consumer outcomes and instrumentation over unprompted source expansion. Explicit
scheduler/executor proof is required before claiming unattended operation.
## 11. Open research questions
1. Is the current responsibility model minimal?

41
templates/PatternUseReceipt.yaml Normal file
View file

@ -0,0 +1,41 @@
# Draft contract for FEP-WP-0008-T02; not an enabled collector or real-use evidence.
# The implementation must turn this into a strict versioned schema and validate it.
# Consumer produces immutable events; collector supplies independently verified origin.
schema_version: 1
use_id: "<consumer-repo>:<task-id>:<decision-id>"
event_id: "<unique-event-id>"
previous_event_sha256: null # Follow-up must name the prior event digest; never overwrite.
recorded_at: "<RFC3339 timestamp>"
kind: synthetic # real only for an actual consumer decision; never change a fixture to real.
consumer:
repo: "<repo slug>"
revision: "<full commit SHA>"
task_ref: "<repo-relative work record path and stable task ID>"
producer: "<agent or person identity>"
run_ref: "<execution receipt locator>"
reference:
version: "0.1"
packaging_revision: "<full commit SHA containing reference files>"
manifest_sha256: "<sha256 of consumed manifest>"
context:
problem: "<short frontend decision>"
constraints: []
considered: [] # Stable CAND IDs; empty is valid for no match.
selected: []
decision:
action: no-match # applied | adapted | rejected | no-match
reason: "<why the guidance was used, changed or rejected>"
artifact_ref: null # Pinned consumer decision/implementation diff when available.
outcome:
value: unknown # helpful | harmful | mixed | no-effect | unknown
basis: consumer-report # consumer-report | model-assessment | observed-result
stage: decision # decision | implementation | test | operation
expectation: "<observable criterion, recorded before assessing the result>"
observation: null
evidence_refs: [] # Authorized artifact/test locators; no pasted private code or secrets.
next_observation: "<linked test/review/outcome condition, or null if complete>"
measured_decision_minutes: null
measured_rework_minutes: null
comparison_ref: null # Needed to claim improvement over a baseline.
# Collector records origin repo/ref/file digest and validation result separately;
# it must not trust producer-written origin verification or rating as proof of benefit.

11
workplans/FEP-WP-0004-reference-surface.md
View file

@ -8,7 +8,7 @@ status: proposed
owner: codex
topic_slug: canon
created: "2026-09-24"
updated: "2026-09-24"
updated: "2026-09-27"
state_hub_workstream_id: "831bbc30-30c0-5df3-a315-5355cd3b8ee5"
---
@ -50,3 +50,12 @@ state_hub_task_id: "ab66848b-1045-54dd-9711-52c5560faafa"
```
Study at least two contrasting accessible repositories at recorded revisions. Separate observed implementation from inferred intent. Write research/reviews/M3-EmpiricalReview.md, publish limitations, and hand remaining findings into live work records.
## User-directed early reuse loop — 2026-09-27
WP-0008 owns an early qualified-reference pilot and consumer outcome instrumentation,
authorized by the user's request for autonomous ecosystem improvement. It may proceed
before M1/M2. It is distinct from this workplan's canonical export and held-out M3
claims; it does not rename consumed feedback into unseen evaluation cases. This plan
remains proposed with its original task gates. Routine reuse must not await those
claims or require a human survey; preserve evidence provenance and honest unknowns.

140
workplans/FEP-WP-0008-use-driven-improvement.md Normal file
View file

@ -0,0 +1,140 @@
---
id: FEP-WP-0008
type: workplan
title: "Close the ecosystem reuse and improvement loop"
domain: infotech
repo: frontend-patterns
status: active
lane: blue
owner: codex
topic_slug: canon
created: "2026-09-27"
updated: "2026-09-27"
---
# 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
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: progress
priority: high
lane: blue
```
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: todo
priority: high
lane: blue
```
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: todo
priority: high
lane: blue
```
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.