[ops]: split Pester execution monolith into context/runtime/selection/execution/post layers

[svelderrainruiz]

Problem

Pester (execution only) still behaves like a monolith even after the service-model split. It currently mixes:

• repo/control-plane context
• host/runtime preflight
• test selection and dispatcher shaping
• actual execution
• post-execution classification and receipts

The standing-priority false negative observed during the self-hosted execution path proves the leak: a repo-control-plane concern can still surface as an execution-seam failure.

Current evidence:

• direct operator proof run 23806250860 admitted the trusted router and cleared readiness
• the active long pole is pilot / pester-run / Pester (execution only) on GHOST-comparevi-capability-ingress
• standing-priority discovery is correct in the repo itself (#2069 is open and labeled standing-priority), so this defect class is about execution-layer coupling, not actual queue state

Objective

Break Pester (execution only) into coherent layers so each failure class is attributable to one contract boundary.

Target layers:

1. pester-context
2. pester-runtime-preflight
3. pester-selection
4. pester-execute
5. pester-post

Implementation Plan

1. Add a context layer and receipt

Create an explicit pester-context stage ahead of readiness/execution.

Responsibilities:

• resolve repository slug deterministically
• validate workflow token presence/usability for issue discovery
• run standing-priority sync or emit an explicit non-blocking context classification
• validate worktree/helper-root assumptions if they are needed by downstream scripts
• emit pester-context-receipt@v1

Outputs:

• context_status: ready | blocked | warning
• repository
• standing_priority_issue
• standing_priority_reason
• receipt artifact

2. Make runtime preflight consume context, not discover context

Refactor self-hosted readiness to assume repo/control-plane context is already settled.

Responsibilities:

• validate session-lock health
• validate .NET toolchain and runtime dependencies
• validate Windows Docker runtime
• validate LVCompare and idle LabVIEW state
• prepare fixture prerequisites only
• emit pester-selfhosted-readiness-receipt@v1

Non-goal:

• no standing-priority or issue discovery here

3. Add a selection layer

Create a pester-selection contract between readiness and execution.

Responsibilities:

• normalize integration mode
• resolve include/exclude patterns
• materialize dispatcher profile
• resolve the concrete test pack/file selection
• emit pester-selection-receipt@v1

This separates test-shaping defects from dispatcher/runtime defects.

4. Shrink execution to execution only

Reduce pester-execute to one job: run the dispatcher against a prepared environment.

Responsibilities:

• consume context, readiness, and selection receipts
• acquire/release execution lock
• run Invoke-PesterTests.ps1
• emit raw execution outputs and a minimal execution exit contract

Non-goals:

• no standing-priority sync
• no repo slug resolution
• no readiness probing
• no test-pack shaping

5. Move classification into post-processing

Create pester-post as the only place that turns raw execution into operator meaning.

Responsibilities:

• release lock defensively
• write execution receipt
• upload raw artifacts
• classify terminal status as one of:
  • completed
  • test-failures
  • context-blocked
  • readiness-blocked
  • selection-blocked
  • seam-defect

6. Remove context ownership from Invoke-PesterTests.ps1

Invoke-PesterTests.ps1 should become context-agnostic.

Required outcome:

• it must not own standing-priority lookup or repository-priority decisions
• it must assume context/readiness/selection were already proven upstream
• it may still own dispatcher/runtime/test orchestration

7. Add contract tests per layer

Add workflow and receipt tests for:

• context-ready path
• context-blocked path
• readiness-ready path
• readiness-blocked path
• selection receipt generation
• execution-only path with mocked dispatcher
• post-processing classification for missing summary / skipped / blocked / failures

8. Promote only after additive proof

Rollout sequence:

1. land the layer split additively
2. prove it on direct operator dispatch
3. prove it on same-owner trusted PR routing
4. prove it on integration/** mounted upstream proof
5. only then recast the current monolith as legacy/fallback

Acceptance Criteria

• standing-priority lookup failures surface in pester-context, not pester-execute
• readiness failures surface in pester-runtime-preflight, not as generic execution stalls
• test selection is represented by an explicit receipt
• execution can run without performing repo/control-plane discovery
• post-processing can classify failures without guessing their layer
• at least one end-to-end proof passes on the service-model rail after the split

Risks / Notes

• this is a follow-up slice under #2069, not a replacement for it
• the issue should remain out of standing auto-selection while #2069 stays the epic
• the current run 23806250860 should be preserved as pre-split evidence of the remaining execution-layer ambiguity

[svelderrainruiz]

Started the fork-lane implementation on branch issue/2078-pester-layered-execution and mounted the first slice onto upstream/integration/pester-service-model at 2e9363ecf692268f9813b743f60497ac3c33eba7.

What landed in this first slice:

• new reusable workflow .github/workflows/pester-context.yml
• pester-gate.yml now routes context -> readiness -> execution -> evidence
• pester-run.yml now requires and validates a context receipt before execution
• pester-evidence.yml now classifies context-blocked distinctly from readiness-blocked
• service-model docs and workflow-contract tests updated to reflect the five-layer split

Local proof completed before mount:

• node tools/npm/cli.mjs ci
• node --test tools/priority/__tests__/pester-service-model-workflow-contract.test.mjs
• node tools/lint-markdown.mjs
• ./bin/actionlint -color .github/workflows/pester-context.yml .github/workflows/pester-gate.yml .github/workflows/pester-run.yml .github/workflows/pester-evidence.yml
• git diff --check

Next move is the upstream integration proof on the mounted branch, using the service-model gate directly.

[svelderrainruiz]

Added the reusable two-layer fork-lane model on the fork branch only at 6c1ac1fe9d3d3ff72b0faa08ad0188dce53d3794.

What exists now:

• instance schema: docs/schemas/fork-lane-instance-v1.schema.json
• index schema: docs/schemas/fork-lane-index-v1.schema.json
• reusable template: tools/priority/fork-lanes/template.yaml
• active index: tools/priority/fork-lanes/index.yaml
• issue instance: tools/priority/fork-lanes/issue-2078.yaml
• schema proof: tools/priority/__tests__/fork-lane-schema.test.mjs

This keeps the design two-layered:

• reusable contract and template survive after issue closure
• per-issue instance manifests remain durable evidence records

The generic model is intentionally fork-side only for now. It is not mounted onto the upstream integration rail.

[svelderrainruiz]

Added a hosted fork-side CI lane for the design audit on branch issue/2078-pester-layered-execution at e308e459c2d748e7ccaa33bb5a516f08e727f5bd.

What the lane adds:

• workflow: .github/workflows/fork-lane-design-audit.yml
• audit runner: tools/priority/fork-lane-design-audit.mjs
• audit policy: tools/priority/fork-lanes/design-audit-policy.json
• report schema: docs/schemas/fork-lane-design-audit-report-v1.schema.json
• tests: tools/priority/__tests__/fork-lane-design-audit.test.mjs, tools/priority/__tests__/fork-lane-design-audit-workflow-contract.test.mjs

Local proof passed before push:

• node --test tools/priority/__tests__/fork-lane-schema.test.mjs tools/priority/__tests__/fork-lane-design-audit.test.mjs tools/priority/__tests__/fork-lane-design-audit-workflow-contract.test.mjs
• node tools/priority/fork-lane-design-audit.mjs --output tests/results/_agent/fork-lanes/fork-lane-design-audit-report.local.json --summary-output tests/results/_agent/fork-lanes/fork-lane-design-audit-summary.local.md
• ./bin/actionlint -color .github/workflows/fork-lane-design-audit.yml
• git diff --check

Current audit outcome:

• status: pass-with-actions
• open findings: fork-capability-contract, lifecycle-closure-contract
• action items:
  • add-fork-capability-attributes
  • add-lifecycle-closure-rules

This lane stays fork-side only. It audits the design continuously without requiring a fork-side self-hosted runner.

[svelderrainruiz]

Local fork-lane assurance is now passing on fork branch issue/2078-pester-layered-execution at 37b9a3d1.

What changed:

• added a local assurance runner: tools/priority/fork-lane-local-assurance-ci.mjs
• added a scoped audit surface manifest: tools/priority/fork-lanes/audit-surface.yaml
• added the minimal assurance packet the standards audit was actually asking for:
  • SRS + RTM
  • architecture packet + ADR
  • CM plan + release procedure
  • test plan
  • quality report
  • information item map

Current local assurance result:

• overall: pass
• action items: 0
• REQ: 5
• ARCH: 5
• TEST: 3
• CM: 3
• DOC: 3

Validation:

• node --test tools/priority/__tests__/fork-lane-schema.test.mjs tools/priority/__tests__/fork-lane-design-audit.test.mjs tools/priority/__tests__/fork-lane-design-audit-workflow-contract.test.mjs tools/priority/__tests__/fork-lane-local-assurance-ci.test.mjs
• node tools/priority/fork-lane-local-assurance-ci.mjs
• git diff --check

This closes the audit-surfaced remediation loop for the current fork-lane baseline. The remaining uplift, if we choose to pursue it, is no longer missing control-plane artifacts; it is managed-level hardening for TEST/CM/DOC beyond the current defined baseline.

[svelderrainruiz]

Started the bigger Pester service-model move on the fork.

New fork-side assurance packet on issue/2078-pester-layered-execution at a47d59e7:

• docs/requirements-pester-service-model-srs.md
• docs/rtm-pester-service-model.csv
• docs/architecture/pester-service-model-control-plane.md
• docs/architecture/ADR-2078-pester-service-model-requirements.md
• docs/cm-plan-pester-service-model.md
• docs/release-procedure-pester-service-model.md
• docs/testing/pester-service-model-test-plan.md
• docs/pester-service-model-quality-report.md
• docs/pester-service-model-information-item-map.md
• tools/priority/fork-lanes/pester-service-model-audit-surface.yaml
• package entrypoint: npm run priority:fork-lane:assurance:pester-service-model

This packet models the Pester plane as a specified subsystem with explicit layers:

• trusted router
• context
• readiness
• execution
• evidence
• additive promotion boundary

Local proof:

• node --test tools/priority/__tests__/pester-service-model-workflow-contract.test.mjs
• node tools/priority/fork-lane-local-assurance-ci.mjs --surface tools/priority/fork-lanes/pester-service-model-audit-surface.yaml --results-dir tests/results/_agent/pester-service-model/local-assurance --output tests/results/_agent/pester-service-model/local-assurance/pester-service-model-assurance-report.json --summary-output tests/results/_agent/pester-service-model/local-assurance/pester-service-model-assurance-summary.md
• git diff --check

Current assurance result:

• overall: pass
• action items: 0
• REQ: 5
• ARCH: 5
• TEST: 3
• CM: 4
• DOC: 3

So the service model is no longer only executable; it is now specified, traceable, and locally auditable on the fork.

[svelderrainruiz]

Started the next managed-level hardening move on the Pester service-model packet and pushed it on the fork at 60d60ef3.

What changed:

• added fork-side quality workflow: .github/workflows/pester-service-model-quality.yml
  • job PR Coverage Gate / coverage
  • job Docs link check / lychee
• added a real coverage helper instead of a placeholder:
  • tools/priority/write-node-test-coverage-xml.mjs
• added contract/tests:
  • tools/priority/__tests__/pester-service-model-quality-workflow-contract.test.mjs
  • tools/priority/__tests__/write-node-test-coverage-xml.test.mjs
• added local docs-check entrypoint:
  • npm run priority:fork-lane:docs:check:pester-service-model
• installed Lychee locally at ~/.local/bin/lychee

Local validation:

• ~/.local/bin/lychee --no-progress docs/knowledgebase/Pester-Service-Model.md docs/architecture/pester-service-model-control-plane.md docs/architecture/ADR-2078-pester-service-model-requirements.md docs/cm-plan-pester-service-model.md docs/release-procedure-pester-service-model.md docs/requirements-pester-service-model-srs.md docs/pester-service-model-quality-report.md docs/pester-service-model-information-item-map.md
• node --test tools/priority/__tests__/pester-service-model-workflow-contract.test.mjs tools/priority/__tests__/pester-service-model-quality-workflow-contract.test.mjs tools/priority/__tests__/write-node-test-coverage-xml.test.mjs
• node tools/priority/fork-lane-local-assurance-ci.mjs --surface tools/priority/fork-lanes/pester-service-model-audit-surface.yaml --results-dir tests/results/_agent/pester-service-model/local-assurance --output tests/results/_agent/pester-service-model/local-assurance/pester-service-model-assurance-report.json --summary-output tests/results/_agent/pester-service-model/local-assurance/pester-service-model-assurance-summary.md
• git diff --check

Updated assurance result:

• overall: pass
• action items: 0
• REQ: 5
• ARCH: 5
• TEST: 5
• CM: 4
• DOC: 5

So the packet is now not only specified and traceable, but also has explicit coverage-gate and docs-integrity evidence on the fork.

[svelderrainruiz]

Checkpoint: the fork packet now has retained release evidence and a promotion dossier.

Branch and commit:

• issue/2078-pester-layered-execution
• e188d437

What landed:

• release-evidence workflow: .github/workflows/pester-service-model-release-evidence.yml
• release-evidence materializer: tools/priority/materialize-pester-service-model-release-evidence.mjs
• promotion dossier renderer: tools/priority/render-pester-service-model-promotion-dossier.mjs
• workflow contract test: tools/priority/__tests__/pester-service-model-release-evidence-workflow-contract.test.mjs

Retained packet evidence now includes:

• coverage.xml
• docs-link-check.json
• pester-service-model-assurance-report.json
• pester-service-model-assurance-summary.md
• release-record-v0.1.0.md
• promotion-dossier.md

Current local assurance result:

• overall: pass
• action items: 0
• REQ: 5
• ARCH: 5
• TEST: 5
• CM: 5
• DOC: 5

This closes the remaining fork-side CM gap and turns the packet into a reusable upstream promotion instrument instead of a fork-only assurance packet.