Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
122 changes: 122 additions & 0 deletions docs/research/council-next-closure-wave-2026-08-26.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,122 @@
# Council report: next Wayfinder closure wave

Date: 2026-08-26
Branch: `dan/wayfinder-durable-passive-launch`

## Decision

Use the Evidence-backed Closure Auditor as the base plan, with containment enforcement from the other two candidates grafted into the portfolio.

The next implementation portfolio is:

1. #111 — prove custody retention and close append-only authority history.
2. #89 — make Workspace the only runtime product-skill authority.
3. #36 — add a deterministic-by-default canonical eval smoke command.
4. #114 — bound uploads and make the named high-risk UI paths keyboard accessible.
5. #21 — finish one passive stored-evidence auth-surface tracer.
6. #41 — add versioned deterministic forensic and policy-fidelity scoring.
7. #37 — connect containment policy to guarded execution and durable audit records.

#87 and #112 remain open. Their current slices are useful, but their remaining acceptance criteria span scheduler generations and the full operator cockpit respectively. #36 and #114 have cleaner seams and are more likely to close honestly in this work block.

## Council settings

- Initial candidates: 2
- Expansion: 1 candidate because the initial pair disagreed on the final lanes
- Judge: parent and neutral subagent
- Isolation: read-only proposals in the shared worktree
- Concurrency: up to 3 council subagents within the 4-agent platform limit
- Reasoning: repository and issue inspection before ranking; no implementation during selection

The candidates were:

- **Forensic Closure Architect:** finish the existing safety and forensic throughline before adding breadth. This tested whether the started #87/#112 work should dominate the next block.
- **Battle-scarred Launch Operator:** maximize operator-visible progress and independent delivery. This tested whether #36/#114 should displace larger continuation work.
- **Evidence-backed Closure Auditor:** maximize high-value tickets that can meet their actual acceptance criteria within the timebox. This resolved the disagreement by inspecting current code and public-path coverage.

## Scoring

Each candidate was scored from 1–5 on safety and forensic impact, honest 4–5 hour closability, dependency value, parallel fit, and rollout/documentation plus stable verification.

| Candidate | Safety | Closability | Dependency value | Parallel fit | Rollout and proof | Total |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| Forensic Closure Architect | 5 | 2 | 5 | 3 | 5 | 20 |
| Battle-scarred Launch Operator | 4 | 4 | 4 | 5 | 5 | 22 |
| Evidence-backed Closure Auditor | 5 | 5 | 5 | 5 | 4 | 24 |

The parent review and neutral judge selected the same base. Both also reached the same correction: omitting #37 would leave an immutable policy that no production executor consumes, so #37 belongs in the final portfolio.

## Ticket approaches and closure bars

### #111 — append-only approval and authorization history

Add direct chain-of-custody assertions for cancelled approvals and revoked authorizations, including original request or grant data, actor, reason, timestamps, and Tool Run linkage. Add explicit terminal-state revival rejection if the existing API tracer does not already prove it.

Close only when the API and custody export together cover every acceptance criterion. This work needs no feature flag.

### #89 — Workspace as the sole product skill registry

Replace the hardcoded prompt and stage skill directory plus the independent filesystem revision cache with one Workspace-backed structured snapshot. Prompt summaries, registry lookup, body load, stage instructions, and the Research Execution Profile revision must report the same IDs and digests. A modified fixture must update every consumer without a process restart, and `.agents/skills` must remain excluded.

Close only after all runtime consumers converge. Incomplete discovery must remain explicit; skill bodies stay bounded and on demand.

### #36 — canonical eval smoke command

Build a thin entrypoint over existing eval modules with `deterministic`, `preflight`, and explicit `live` modes. Deterministic is the default. Missing credentials or providers produce honest blocked or skipped rows rather than false failures or false zero-cost success. Every row records model URI, run mode, cost provenance, `toolCalls`, `maxToolCalls`, and real-versus-mock provenance.

The `live` mode is the high-risk gate. No paid run is required for implementation closure.

### #114 — accessible dialogs and bounded uploads

Add focus trapping and restoration, dirty-dismiss protection, and expected keyboard behavior for the named dialogs, tabs, and listboxes. Enforce file-count and byte admission before hashing or upload work begins, with bounded concurrency, cancellation, and stable per-file outcomes.

Limits and concurrency are meaningful numeric configuration, not boolean flags. Close only with a keyboard-only browser path and an oversized-folder path that proves rejection precedes upload work.

### #21 — passive auth-surface tracer

Add one passive-only service and Mastra tool that accepts stored Artifact IDs, uses the existing normalizer and summary writer, persists RAG metadata and blocker records, and updates one existing Task and system-map path with target and evidence IDs. It returns passive, approval-required, and report-or-patch next actions while calling no HTTP, browser, shell, or Security Action executor.

Use a typed rollout value such as `off | shadow | enabled`, with `shadow` as the initial default. This closes a tracer milestone; leave the large PRD open unless its remaining reference, UI, and workflow criteria are separately audited.

### #41 — forensic and policy-fidelity scoring

Add a versioned deterministic scorer for evidence linkage, target and approval binding, tool-budget fidelity, recovery, correct refusal, false refusal, and no-finding behavior. Feed its structured output into existing reports while keeping semantic judgment separate.

The scorer version is the rollout control. Historical rows retain their original version. No paid matrix is required for this slice.

### #37 — containment enforcement and audit

Connect the normalized containment policy to Security Action Execution. Persist the policy ID and content hash on Tool Runs and resulting Artifacts, and project the same identity into eval provenance. Existing target and approval guards remain mandatory.

Use a persisted mode such as `shadow-v1 | enforce-v1`. Shadow mode records divergence but never grants authority. Enforce mode fails closed on expiry, target or destination drift, path escape, network mismatch, DNS mismatch, and approval-intent mismatch before side effects.

Close only when passive and approval-gated execution tracers prove the same policy identity and durable diagnostics.

## Parallel waves

### Wave 1

- Parent: #111 custody proof and closure audit
- Worker A: #89 Workspace convergence
- Worker B: #36 deterministic smoke entrypoint
- Worker C: #114 accessibility and upload admission

### Wave 2

- Worker A: #21 passive stored-evidence tracer
- Worker B: #41 deterministic scorer and report integration
- Worker C: #37 shadow/enforce executor integration
- Parent: shared registration, documentation, combined verification, and close-versus-partial audit

## Deferred work

- **#87:** follow #89 and #37 so the profile can pin their real revisions and policy identity. The scheduler still constructs an ad hoc handoff profile.
- **#112:** follow durable blocker persistence and the evidence-original policy decision. The Target inventory API is only one part of the XL cockpit issue.
- **#106–#108:** do not infer the unresolved original-versus-redacted custody policy.
- **#123:** no paid four-mode matrix in this block.
- **#38, #39, #40, #42:** do not widen enforcement work until #37 has a real guarded executor consumer.
- **Wayfinder/device expansion:** keep the campaign foundation commits, but finish the passive-launch contracts before adding more durable concepts.

## Verification contract

Each ticket gets its focused public-path test before its commit. Run combined integration and deterministic eval suites at wave boundaries. Keep the known Next route-export type failures visible rather than treating them as passing. Close GitHub issues only when the acceptance criteria are observable through the product or export seam; otherwise leave a concrete partial-work comment with the remaining gap.
238 changes: 238 additions & 0 deletions docs/research/council-next-ticket-portfolio-2026-08-26.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,238 @@
# Council of Dans: next implementation portfolio

Date: 2026-08-26

## Decision

Build a durable passive-launch path before active campaign automation. The next branch
will make authority and run configuration reconstructable, unify runtime skill discovery,
and ship one passive auth-surface workflow. It stops before active campaign execution,
external egress redesign, paid model studies, or any unresolved Wayfinder HITL decision.

The selected tickets are:

1. [Make approval and authorization history append-only](https://github.com/justsml/ExploitHunter.app/issues/111)
2. [Pin an immutable Research Execution Profile to every run](https://github.com/justsml/ExploitHunter.app/issues/87)
3. [Make Mastra Workspace the sole product skill registry](https://github.com/justsml/ExploitHunter.app/issues/89)
4. [Build the reference-backed passive recon and auth-surface mapping loop](https://github.com/justsml/ExploitHunter.app/issues/21)
5. [Expose canonical Evidence, cockpit queues, and Target inventory](https://github.com/justsml/ExploitHunter.app/issues/112), narrowed to durable blockers and the Target inventory tracer
6. [Create a unified containment policy module](https://github.com/justsml/ExploitHunter.app/issues/37)
7. [Make validation authority explicit and measure model guardrails](https://github.com/justsml/ExploitHunter.app/issues/100), limited here to the four-mode implementation contract

## Council frame

- Candidate count: three solution candidates plus one neutral judge.
- Initial concurrency: two read-only candidates.
- Expansion: one candidate after the initial reports disagreed on whether operational
repairs should block passive product integration.
- Judge: parent and neutral read-only subagent.
- Isolation: read-only repository and issue-tracker inspection; exact reports were
exported to separate temporary files for neutral judging.
- Reasoning: inherited high-effort planning and architecture analysis.

Every candidate delivered a complete 5–8 ticket portfolio against five criteria:

1. close a user-visible flywheel gap;
2. preserve authorization, eval honesty, and forensic evidence;
3. fit the Mastra-first architecture and project domain language;
4. support independent vertical commits with limited file overlap; and
5. define realistic public-seam verification.

## Solution families

### Candidate A: Throughline Architect

This family proposed converting the existing Wayfinder foundations directly into a
persisted path: execution profile, ecosystem selection, Target Recipe lifecycle, passive
recon, impact workflow, campaign runner, Workspace skill registry, and native-harness
canaries. Its decision value was testing whether forward integration should outrank
operational repair.

### Candidate B: Battle-scarred Minimalist

This family proposed closing append-only authority, containment, validation-authority,
external egress, adversarial containment, cockpit, and accessibility gaps before running
the new campaign contracts. Its decision value was testing whether the current runtime
could support trustworthy campaign evidence.

### Candidate C: Evidence-backed Integrator

This family inspected the concrete seams behind the disagreement. It found destructive
decision deletion, no canonical Research Execution Profile, two product-skill catalogs,
no passive discovery normalizer, process-local blocker state, split containment inputs,
and model-facing validation authority. It proposed a mixed but ordered portfolio:
minimum forensic gates, then a passive user workflow, then containment and authority
convergence.

## Judging

The parent and neutral judge selected Candidate C. The neutral scores were:

| Criterion | A | B | C |
| --- | ---: | ---: | ---: |
| User-visible flywheel value | 5 | 3 | 5 |
| Authorization, eval-honesty, and forensic safety | 4 | 5 | 5 |
| Mastra-first architecture and domain fit | 5 | 4 | 5 |
| Independent commit feasibility | 4 | 4 | 4 |
| Public-seam proof and realistic scope | 4 | 4 | 5 |
| **Total** | **22** | **20** | **24** |

The parent reached the same ordering. No criterion-level disagreement changed the base.
Candidate C retained Candidate A's user-facing passive throughline without accepting its
proposal to operationalize unresolved Wayfinder decision tickets. It retained Candidate
B's minimum forensic gates without placing external egress or a containment eval ahead
of the canonical containment-policy seam.

## Grafts

From Candidate A:

- Preserve the full passive path: stored Artifact, normalized auth surface, summary
Artifact and RAG indexing, Tasks and system map, blockers, and categorized next actions.
- Normalize response families, auth/session observations, confidence, and raw Artifact
references.
- Keep zero-target native-harness canaries as the next eval step after execution-profile
and containment provenance are trustworthy.

From Candidate B:

- Make non-draft decision deletion impossible and preserve revocation actor, reason,
time, and Tool Run linkage.
- Require the containment policy to drive at least one guarded action and persist its
digest on the Tool Run; a policy object with no executor consumer does not satisfy the
ticket.
- Order external egress and adversarial containment after the normalized containment
policy, with a real local enforcement-boundary test before claiming completion.

## Ticket approaches

### 1. Append-only approval and authorization history

Replace physical deletion of terminal or used decisions with durable revocation or
cancellation. Define draft-only deletion server-side. Preserve original request,
decision, actor, reason, timestamps, consumption, and Tool Run linkage in list and
chain-of-custody paths.

Public proof: create and consume a decision through the API, reject deletion and revival,
revoke it, then reconstruct the original record and consumption linkage.

### 2. Immutable Research Execution Profile

Resolve one versioned snapshot before publishing a run. It owns requested and effective
model envelopes, stage overrides, capability and skill revisions, target mode,
containment reference, budgets, UI collection, and policy versions. Main controller,
stages, scheduler work, recovery, and exports must consume the same generation.

Public proof: start a research run, change defaults, resume or inspect it, and show that
the active run retains its original profile while a later run gets the new generation.

### 3. Workspace-owned product skill registry

Derive prompt summaries and model-facing lookup from reviewed Mastra Workspace skill
records. Add stable IDs and content digests, bounded bodies, invocation-time revalidation,
and explicit incomplete-discovery state. Maintainer `.agents/skills` remain excluded.

Public proof: Workspace search, prompt directory, and registry tool return the same IDs
and digests; a changed skill invalidates stale content without restart.

### 4. Passive recon and auth-surface mapping

Add a pure discovery normalizer for stored evidence and one service/tool that writes a
redacted summary Artifact, indexes it through the shared evidence path, updates Tasks
and system-map relationships, records blockers, and separates passive next steps from
approval-required work. This slice performs no network, browser, or shell action.

Public proof: feed a noisy stored transcript through the Mastra tool and retrieve the raw
and summary Artifact linkage, RAG metadata, Task/map updates, blockers, and categorized
next steps with zero action execution.

### 5. Durable blockers and Target inventory

Replace the default process-local blocker repository with a durable database-backed
repository. Extend the existing cockpit projection and add a read-only project Target
inventory API using canonical Target IDs, relationships, scope, and current/historical
authorization state. Do not redesign the dashboard or invent raw-original access policy.

Public proof: create records, reconstruct services as if after restart, and retrieve the
same canonical blocker, Target, authority, Artifact, Finding, and tool-failure identities.

### 6. Unified containment policy

Normalize target identity, destinations and ports, DNS posture, network profile,
workspace bounds, mounts, isolation, resource and time limits, expiry, and approval
intent into an immutable digest. The existing Security Action Execution module remains
the executor and consumes the policy for one passive and one gated action.

Public proof: matching actions persist the policy digest on Tool Runs; expiry, destination
drift, path escape, network mismatch, and changed approval intent fail before execution
with inspectable diagnostics.

### 7. Explicit validation authority

Implement `strict | auto | self | yolo` as the sole validation-authority vocabulary.
Persist the mode on the execution profile, Tool Run, validation execution, usage/eval
record, and evidence export. Executor observations and model assertions remain distinct.
This branch does not run the paid or repeated matched matrix.

Public proof: run the same fixture through all four modes and verify authority source,
approval consumption, evidence provenance, terminal transition ownership, and mode
immutability across recovery.

## Parallel implementation waves

The shared worktree supports three subagents plus the integrator. Per-ticket commits are
possible only with strict ownership and selective staging; subagents must not make global
commits.

### Wave 0

- Worker A: append-only decisions.
- Worker B: execution-profile schema and resolver, deferring shared migration edits to
integration.
- Worker C: Workspace-backed skill registry.
- Integrator: passive normalizer and fixtures.

### Wave 1

- Durable blockers and Target inventory after append-only decisions.
- Passive service/tool integration after the durable blocker seam.
- Containment policy after the execution-profile identity is fixed.

### Wave 2

- Four-mode validation authority after append-only decisions, execution profile, and
containment policy.
- Combined passive-path verification and repository-level checks.

Each ticket lands as one selectively staged commit. Shared migrations, database types,
barrel exports, and documentation are serialized by the integrator.

## Rejected work

- Do not operationalize the open ecosystem, Target Recipe, anomaly, autonomy, skill,
harness, first-campaign, or device Wayfinder decisions merely because reversible
foundation contracts exist.
- Do not build the active campaign runner before append-only decisions, execution
profiles, containment, and explicit validation authority.
- Do not implement external egress or its adversarial eval before the canonical
containment policy exists.
- Do not begin a paid/native model matrix, target-backed campaign, remote compute job,
firmware acquisition, or device interaction in this portfolio.
- Keep accessibility/upload bounds as the next independent UI-quality lane rather than
mixing it into these flywheel commits.

## Verification contract

Every commit receives its focused integration or eval check and a full TypeScript check.
Wave boundaries run the combined focused suites. The final tracer proves:

```text
stored project Artifact
-> passive auth-surface normalization
-> summary Artifact and RAG metadata
-> Task, system map, and durable blocker state
-> categorized passive or approval-required next action
```

No step in that tracer creates target authorization, approval, a Finding, or an active
target action.
Loading