← Operations Web Function

One Master Graph and the Self-Improving Task Library

Master registry graph and recursive learning contract · Operations Web Function 0.1.0.

Download the complete plugin · Source SHA-256: 8a10ce7fad62ae13493d0ab636654cae8078628afe7df52ee4f58999131f8a9e

The Web Function must not become a second library that competes with existing BlitzMetrics tasks or skills. It is a portable Operations control plane that assembles existing canonical methods and proposes only the missing bounded tasks and Web-specific interfaces.

One graph, artifact-level owners

"One master" means one machine-readable registry graph with exactly one owner for each artifact—not necessarily one monolithic repository.

This candidate pins the inspected Task Library commit in registry/capability-map.json. The reusable Web Function skills are not canonical until merged into the marketplace with a commit and source path. registry/source-state.json leaves those values null on purpose.

The four linked knowledge artifacts

1. Exact task page — one bounded outcome with inputs, steps, errors, verification, and an observable Definition of Done.
2. Definitive article — the broader concept hub that the task belongs to.
3. Skill — agent-readable execution instructions for the task or orchestration layer.
4. Meta examples — structured, dated records of real executions, including confidence, reviewer, retrieval date, evidence, limitations, and fingerprint.

Do not collapse these four into one URL merely for convenience. The Web Function hub at https://localservicespotlight.com/web-function/ is the definitive Operations concept page. The generated /skills-* pages are candidate implementation pages. The detailed /web-function-sop/ page is a subordinate reference, not a competing canonical hub. The five packaged case studies are candidate examples until accepted into the Task Library's structured historical-example registry.

Source and projection rule

For every registry row, record repository, commit, path, source hash, artifact type, implementation URL, exact task URL when applicable, definitive hub, canonical owner, dependency state, and evidence history.

reviewed artifact owner at pinned commit
→ generated exact-task or implementation page
→ versioned release archive
→ installed or fleet mirror

If downstream copies disagree, compare them with the registry row's pinned source. Correct the narrowest owned source, review it, then regenerate. Do not use newest modification time, hand-edit a generated page, or treat a ZIP as an update channel.

Overlap gate

Before adding or changing a skill:

1. Search both canonical repositories, the Task Library registry, definitive articles, scheduled prompts, and existing adapters.
2. If an owner exists, invoke or improve it. A Web Function wrapper may add trigger/context/receipt bindings; it may not copy the owner's method.
3. Create a new bounded task only when no existing task owns the result, it has literal triggers and one Definition of Done, and it is registered through review.
4. Classify orchestrators, aliases, adapters, and control envelopes as implementations/supporting artifacts—not Task Library tasks.
5. Give each capability exactly one canonical_owner. Every delegate must resolve to a pinned skill or be explicitly UNRESOLVED.
6. Resolve exact task_refs for each job at build time and write the resolved slugs plus pinned Task Library commit into its receipt.
7. Preserve one writer per file and one active collector per schedule/SLA. A wrapper cannot create a second verdict engine or overlapping job.

Current collision decisions

The learning loop

Task Library registry
→ exact task page
→ definitive concept article
→ canonical skill source
→ versioned job
→ immutable receipt
→ structured meta article
→ QA flag + regression test
→ reviewed source change
→ regenerated page and bundle
→ fresh-chat canary
→ observed run receipt
↺

Every meta article records the run ID, job/skill versions and hashes, pinned task/skill sources, target, inputs, steps actually taken, decisions, deviations, guesses, systems, duration, evidence, outcome, unknowns, QA flags, owner, correction, failing-then-passing regression test, redaction decision, supersession links, public read-back, and next trigger. Publication does not make it an accepted Task Library example; reviewer and registry receipts do.

Evidence states

• Available: merged in the canonical marketplace.
• Delivered: link or file reached a recipient.
• Installed: a named environment shows the plugin.
• Enabled: that environment permits use.
• Tested: a fresh chat triggers the expected skill.
• Scheduled: a scheduler registration has an owner and read-back.
• Observed: a timestamped firing produced an immutable output or unedited failure.

Version 0.1.0 is a delivered, locally validated candidate control plane. It is not yet merged, Task Library registered, installed, enabled, or observed by an adopter. The separate Codex fleet audit already running for BlitzMetrics is evidence about that environment, not proof that this downloadable package scheduled itself.

Current references

• Meta articles and definitive articles
• Definitive article guide
• How to document a task
• Task Library — one current index route; canonical/redirect reconciliation remains open across historical routes.
• Always Boil the Ocean
• Web Function definitive hub

Definition of Done

This integration is complete only when every artifact has one owner and pinned source; every dependency and task reference resolves or fails loudly; duplicate capability owners and overlapping active schedules fail validation; public pages expose provenance and candidate/canonical status; cases have structured example records; the marketplace and Task Library changes are reviewed; fresh-chat canaries pass; and the first intended run is observed by an immutable receipt that traces task → skill → job → evidence → learning disposition.

This page is generated from docs/MASTER-SOURCE-AND-LEARNING-LOOP.md. Do not hand-edit the public copy.