feat: promote lab workflow library and retire learn surface

.agents/skills/omp-flow-check/SKILL.md

@@ -36,10 +36,33 @@ substitute for the practice result.
 4. Verify applicable linked decisions, interfaces, and source constraints.
 5. Run independent focused tests and broaden checks for shared behavior or contracts.
 6. Write the Review Concept at the supplied output path, link it to the work and handoff, lead
-   with severity-ordered findings, and record exact commands/results.
+ with severity-ordered findings, give every finding all applicable `HARD_BLOCKER`,
+ `PRINCIPAL_BLOCKER`, `WORK_FAIL`, and `ADVISORY` labels, and record exact commands/results.
 
-PASS requires zero failed tests, no unresolved blocking finding, and full scope satisfaction. A
-substantive finding returns FAIL to the owning work; do not repair it and approve your own change.
+The bounded Work may be `PASS` only when all of these hold:
+
+- its own authored acceptance criteria are satisfied;
+- the linked principal product checkpoint is not blocked, and any required principal-checkpoint
+  linkage is present;
+- every test that exercises the Work's acceptance criteria or the linked principal checkpoint
+  passes.
+
+A finding that violates a non-negotiable boundary is `HARD_BLOCKER`; one that concretely prevents
+the linked principal checkpoint is `PRINCIPAL_BLOCKER`. A failed Work acceptance criterion or test
+exercising it is `WORK_FAIL`, and labels may overlap. If the failed Work is required for the next
+principal checkpoint, it is also `PRINCIPAL_BLOCKER`. Any `HARD_BLOCKER`, `PRINCIPAL_BLOCKER`, or
+`WORK_FAIL` makes the bounded Work `FAIL`; only `HARD_BLOCKER` and `PRINCIPAL_BLOCKER` pause the
+principal path. A `WORK_FAIL` without either stronger label enters the recorded owning-Work
+backlog. When the principal checkpoint produces `continue`, `narrow`, or `stop`, that backlog
+requires explicit human/design routing for repair, deferral, removal, narrowing, or stop; it does
+not autonomously create repair/review work or preempt the principal queue.
+
+A failed test may be `ADVISORY` only when the reviewer records evidence that it is unrelated to
+the Work acceptance and principal checkpoint, pre-existing, and separately attributable, with the
+exact command and result. Missing or ambiguous attribution is not a basis for `PASS`.
+`ADVISORY` findings remain explicit residual risk but do not make the Work `FAIL`, reopen accepted
+Work, or preempt the principal checkpoint. `PASS` may carry only those explicitly attributed
+unrelated red tests and other advisory findings.
 
 ## Red Flags
 

.agents/skills/omp-flow-execute/SKILL.md

@@ -36,18 +36,35 @@ description: Coordinate native implementation and independent review from approv
    runs independent checks, and writes the promised Review Concept.
 5. Finish with the same reviewer actor ID. Read the review's findings and verdict as knowledge;
    Python does not parse or duplicate them into Evidence or row status.
-6. A substantive failure returns to the owning work/design Concept for repair and another
-   independent review. Material design changes repeat the applicable QbD decision.
+6. Classify every finding with all applicable labels:
+   - `HARD_BLOCKER` violates a non-negotiable safety, authority, identity, integrity,
+     assignment/receipt/source-binding, or irreversible-effect boundary;
+   - `PRINCIPAL_BLOCKER` concretely prevents the next authored principal product checkpoint;
+   - `WORK_FAIL` violates the bounded Work's own acceptance criteria or a test that exercises
+     them; it may overlap either stronger label;
+   - `ADVISORY` is any other recorded quality, robustness, completeness, or elegance risk.
+   A failed prerequisite Work required by the next principal checkpoint is also
+   `PRINCIPAL_BLOCKER`. `HARD_BLOCKER` and `PRINCIPAL_BLOCKER` pause the principal path and
+   return to the owning work/design Concept for explicit routing. `WORK_FAIL` makes that Work
+   `FAIL` and enters a recorded owning-Work backlog; absent a hard/principal label it must not
+   autonomously create repair/review work, reopen accepted Work, or preempt the principal
+   checkpoint. `ADVISORY` remains recorded residual risk and has none of those effects.
+7. A hard/principal failure requires explicit human/design routing. When the principal checkpoint
+   produces `continue`, `narrow`, or `stop`, present every recorded `WORK_FAIL` backlog to the
+   human/design decision for explicit repair, deferral, removal, narrowing, or stop; none of those
+   routes is autonomous. Material design changes repeat the applicable QbD decision.
 
 For native batch execution, repeat `operation start` for every item. Preserve each independent
 `(id = actorId, role, assignment)` tuple; never share an operation, assignment, actor ID, receipt,
 or rewritten prompt across items.
 
 ## Completion
 
-Continue without asking "should I continue?" until the accepted work has linked independent
-reviews, a real blocker needs user input, or design/work must return through a gate. Then load
-`omp-flow-finish`.
+Continue through the authored work order toward the next principal product acceptance checkpoint.
+Do not let `WORK_FAIL` backlog or `ADVISORY` findings preempt that checkpoint. Stop autonomous
+continuation when a `HARD_BLOCKER` or `PRINCIPAL_BLOCKER` needs a human/design decision or when
+the principal checkpoint has produced its declared continue/narrow/stop evidence; do not
+manufacture completion by clearing every secondary finding.
 
 ## Red Flags
 

.agents/skills/omp-flow-workflow-maintainer/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: omp-flow-workflow-maintainer
+description: Inspect authored Workflow documents and practice evidence, then write a reviewable maintenance candidate without directly promoting production policy.
+---
+
+# OMP-Flow Workflow Maintainer
+
+Use this Skill only for a bounded Workflow Library maintenance Task. The Task Bundle is the source of
+purpose, boundaries, evidence, output, and human decisions.
+
+## Method
+
+1. Read the Task entry and `.omp-flow/workflow/index.md` when it exists. Follow only useful ordinary
+   links to the affected Workflow Markdown, authored fragments, archived Task evidence, Reviews,
+   handoffs, and Sleep Candidates.
+2. Separate repository facts, repeated practice findings, contrary evidence, local exceptions,
+   applicability boundaries, and unresolved questions.
+3. Write the smallest candidate revision in the assigned Task output. State the affected Workflow or
+   fragment, proposed prose change, expected benefit, counterexample, regression risk, and replay or
+   verification plan.
+4. Do not edit canonical production Workflow policy, Skills, Hooks, or Runtime as an automatic result
+   of this maintenance analysis. Promotion is a separate bounded Work after independent review and
+   human decision.
+5. If a production change is authorized, the Main session creates the bounded Work and uses
+   `operation start`; forward its complete returned assignment unchanged. Never manufacture an
+   assignment, actor ID, receipt, dependency, or runtime phase.
+
+## Boundaries
+
+- Do not parse Workflow Markdown, folder names, headings, links, or frontmatter into machine state.
+- Do not create a graph runtime, route schema, exact-topology identity, second dispatcher, or
+  automatic Workflow selector.
+- Do not let model name alone select Lite or bypass a required boundary.
+- Do not turn one Task-specific observation into a global Workflow rule without replay, contrary
+  evidence, applicability limits, independent review, and human calibration.
+- Do not spawn another workflow sub-agent.

.agents/skills/omp-flow/SKILL.md

@@ -19,16 +19,16 @@ implement work itself, or manufacture missing knowledge.
 
 ## Start Here
 
-1. Confirm `.omp-flow/workflow.md` and `.omp-flow/scripts/omp_flow.py` exist. If not, stop and ask
-   whether to initialize the requested Harness adapter.
+1. Confirm `.omp-flow/scripts/omp_flow.py` and at least one Workflow source:
+   `.omp-flow/workflow/index.md` or legacy `.omp-flow/workflow.md`. A fresh project should use the
+   index; an existing project may still use the legacy file during migration. If the runtime kernel
+   or both Workflow sources are missing, stop and ask whether to initialize the requested Harness
+   adapter.
 2. Resolve this session's active task directory through the runtime or select one explicitly.
-   `task select <task-id>` works with a native Harness session or the repository-local terminal
-   lane. When concurrent callers may share that terminal lane, pass `--task <task-id>` to commands
-   that accept it; an explicit Task always takes precedence over the convenience pointer. Never
-   borrow another session's active task.
+   Never borrow another session's active task.
 3. Open the Bundle root `index.md`. Follow only links useful to the current request.
-4. Read `.omp-flow/workflow.md` when the Bundle or requested operation needs details not present
-   in this router.
+4. Read `.omp-flow/workflow/index.md` when present, then follow its ordinary links to the Workflow
+   Markdown relevant to this Task. Fall back to `.omp-flow/workflow.md` only for legacy projects.
 5. Treat a missing root index or required entry Concept as a blocker. Do not fall back to
    `task.json`, CSV/JSONL stores, generated context, or chat reconstruction.
 

.claude/skills/omp-flow-check/SKILL.md

@@ -36,10 +36,33 @@ substitute for the practice result.
 4. Verify applicable linked decisions, interfaces, and source constraints.
 5. Run independent focused tests and broaden checks for shared behavior or contracts.
 6. Write the Review Concept at the supplied output path, link it to the work and handoff, lead
-   with severity-ordered findings, and record exact commands/results.
+ with severity-ordered findings, give every finding all applicable `HARD_BLOCKER`,
+ `PRINCIPAL_BLOCKER`, `WORK_FAIL`, and `ADVISORY` labels, and record exact commands/results.
 
-PASS requires zero failed tests, no unresolved blocking finding, and full scope satisfaction. A
-substantive finding returns FAIL to the owning work; do not repair it and approve your own change.
+The bounded Work may be `PASS` only when all of these hold:
+
+- its own authored acceptance criteria are satisfied;
+- the linked principal product checkpoint is not blocked, and any required principal-checkpoint
+  linkage is present;
+- every test that exercises the Work's acceptance criteria or the linked principal checkpoint
+  passes.
+
+A finding that violates a non-negotiable boundary is `HARD_BLOCKER`; one that concretely prevents
+the linked principal checkpoint is `PRINCIPAL_BLOCKER`. A failed Work acceptance criterion or test
+exercising it is `WORK_FAIL`, and labels may overlap. If the failed Work is required for the next
+principal checkpoint, it is also `PRINCIPAL_BLOCKER`. Any `HARD_BLOCKER`, `PRINCIPAL_BLOCKER`, or
+`WORK_FAIL` makes the bounded Work `FAIL`; only `HARD_BLOCKER` and `PRINCIPAL_BLOCKER` pause the
+principal path. A `WORK_FAIL` without either stronger label enters the recorded owning-Work
+backlog. When the principal checkpoint produces `continue`, `narrow`, or `stop`, that backlog
+requires explicit human/design routing for repair, deferral, removal, narrowing, or stop; it does
+not autonomously create repair/review work or preempt the principal queue.
+
+A failed test may be `ADVISORY` only when the reviewer records evidence that it is unrelated to
+the Work acceptance and principal checkpoint, pre-existing, and separately attributable, with the
+exact command and result. Missing or ambiguous attribution is not a basis for `PASS`.
+`ADVISORY` findings remain explicit residual risk but do not make the Work `FAIL`, reopen accepted
+Work, or preempt the principal checkpoint. `PASS` may carry only those explicitly attributed
+unrelated red tests and other advisory findings.
 
 ## Red Flags