One Master Graph and the Self-Improving Task Library

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

Artifact Canonical owner Relationship
Bounded task contract Reviewed Goodrich-Dev/task-library registry row One exact task page, one broader definitive hub, one executable task skill, and structured examples.
Reusable high-level agent skill Merged, validated dennisyu/blitzmetrics-skills source May orchestrate many bounded tasks without being counted as a task.
Definitive article The reviewed broader concept hub named by the registry Owns the durable why, method, and standards.
Exact task page The reviewed task URL named by the Task Library Teaches one observable task and links up to the hub.
Meta article A reviewed historical-example record tied to a task and run receipt Shows one dated execution; it never becomes the SOP.
Job A versioned invocation of resolved skills and task references Adds trigger, context, permission ceiling, lease, idempotency, outputs, and receipt.
Generated page, ZIP, install, mirror Projection of a pinned source graph Must carry provenance and cannot silently outrank its source.

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

Candidate artifact Decision
inventory-web-properties New bounded-task candidate for the authoritative property registry, lifecycle, denominator, and generated projections. Access collection stays with client-access-checklist.
triage-web-incidents New bounded-task candidate for classification, severity, owner, and handoff. security-audit supplies findings.
preserve-web-incident New bounded-task candidate for minimum evidence and custody before remediation. security-audit is an upstream prerequisite, not the same task.
monitor-web-fleet Thin probe/receipt adapter owned by canonical security-audit; it is not a second verdict method. fleet-uptime-monitor remains unresolved until one merged source is found.
govern-web-access Invocation profile for lifecycle, expiry, review, rotation routing, and revocation. client-access-checklist owns access collection and the initial gate.
document-web-lessons Router into recursive-self-improvement-qa, definitive-article-writer, skill-registry, and the Task Library meta task. It owns no second learning queue.
operations-function, operate-web-function Orchestrators/supporting hubs, not bounded Task Library tasks.
change-web-production, verify-web-outcome Cross-task control envelopes; the exact mutation and QA remain owned by their bounded Task Library tasks.

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

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.

Scroll to Top