#############################
##### Mega Plan Harness #####
#############################

NOTE (2026-07-07): This file is the ORIGINAL sketch, kept for history. It is SUPERSEDED by
docs/plans/2026-07-07-design-gap-handoff.md (authoritative plan) and spec/*.md (canonical
implementation specs — start with spec/IMPLEMENTER-NOTES.md). Where this file conflicts
with those, they win.

Compatible with Claude Code Dynamic Workflows - But an independent tool overall.
Shared memory for all agents running.
Meta-orchetrator that is a hybrid programmatic-LLM desicion agent
Self improvement on failure, not just silent fail or a loud error
Agents can communicate with each other.
Each CLI/Supplier is an adapter, codex adapter, claude-code adapter, agy adapter, opencode adapter, claudecode-openrouter adapter,  etc.

Open Knowledge Format 2nd brain for the workflows, shared with the harnesses (claude code, codex, opencode, cursor-agent, etc) so all the agents are always up to date about everything
	- Global knowledge
	- Project knowledge
	- Job knowledge
	- Synchd with Claude Memories (and equivilents from other cli's)
	- Since OKF is not widely used yet, agents need a reminder in CLAUDE/AGENTS.md files to explain how to use the OKF KB, How to navigate the okf KB, what role each file plays in the okf, and how the structure should be used. 
	Example prompt:
		# Repository Navigation Protocol (Open Knowledge Format)

		This repository utilizes the Open Knowledge Format (OKF) to optimize context retrieval, minimize token usage, and prevent duplicate files. You must interact with the codebase using the following rules:

		### 1. Progressive Navigation Rule
		Do not use raw terminal grep commands or blind full-text pattern matching as a first resort. Instead:
		- Start your search at the root `index.md`.
		- Read the one-sentence descriptions of the subdirectories.
		- Move down the directory tree level-by-level, reading the local `index.md` at each stage.
		- Only open the final target concept file once you have identified it via the index summaries.

		### 2. Metadata Filtering
		Before parsing the entire body of a document, look at its YAML frontmatter block. Use the `type` and `tags` fields to quickly determine if the document matches the user's intent without wasting tokens on the full text.

		### 3. Upkeep and Maintenance
		When creating or modifying files, you must maintain the OKF structure:
		- **Single Concept:** Ensure every file represents exactly one minimal topic (do not mix unrelated topics).
		- **Frontmatter:** Every new file must include a YAML frontmatter block containing at minimum a `type` field (along with optional `title`, `description`, and `tags`).
		- **Index Update:** Immediately update the parent directory's `index.md` file to include a markdown link to the new file alongside a clear, one-sentence summary.

#############################
#### Meta Harness Web UI ####
#############################

Web UI Dashboard for watching and interacting with the running agents.
DAG View of the workflow running
Each node in the DAG represents a wave, clickable for expansion show details of the wave, all tasks, all agents running inside the task, agents clickable, clicking on agent leads to the agent view, where you can watch what agent is doing, can interact with the agent (write to the agent) and see all that agent is doing live.

### Imports ###

Use all relevant modules from @platform-modules/mod project - Do not rewrite anything you dont have to. If there are any missing elements, let the user know and we shall plan accordingly, what lives on this project and what needs a module.
Note to agent: You should populate this with all the platform modules required to build this app

################


Web UI Screens:
Overview page
	- Tile view of all jobs (workflows) that are not done yet. (Graphical preview of each workflow inside the tile) 
	- Badge on each tile per status [Running, Paused, Error, Interrupted, etc]
	- Click on Tile takes to Job (workflow) page
	- Quick CTA Hover according to status [Start, Pause, Delete, Info, etc...] with svg icons. Shwo only relevant CTA . f.e. show "Start, Delete, Info" for paused, show "Pause, Info" for Running, etc.
	
Job page
	- All metadata that we have about the job - project folder, type, repo, branch, worktree, 
	- DAG View of the workflow - each Node represents a wave.
	- Badge on each node per status (Running, Paused, Error, Done, etc...)
	- Clicking on wave, expands view to show tasks
	- Inside task should be task title and Agent responsible. 
	- Clicking on agent takes to agent page

Agent page
	- Chatbot template interface
	- Can see the entire history of the agent, prompt, all settings, pid, runtime, idle time, Killswitch , all details we have about the agent. 
	- Live chat history 
	- Can send promtps to agent (text and attachments accordign to agent capability)
	
Open Knowledge Base
	- The place where you can manage OKF
	
Adapter setup page
	- Show all available CLI/adapters
	- Set up each of them
	- Configure each of them
	- Enable/Disable each of them
	- Granularly select which models we can user per adapter. (Openrouter has hundreds of models, we only need 1 or 2, just as an example of why we need it)
	- Adapter health
	
## Self-healing

Failure taxonomy lives in `src/fail-taxonomy.js` (`FAIL_CLASSES`). Runner code must classify errors through it, not string-match ad hoc.

Repair ladder:
	1. Deterministic repair. Dependency provisioning, lockfile drift, journal append retry, unknown journal state, orphan worktree cleanup. Journal `repaired`, then retry the task once.
	2. Fixer repair. Gate-red code gets the task fixer, then one high-tier fixer escalation.
	3. Quarantine. Task is marked `quarantined`; downstream dependents are skipped; unrelated siblings continue.

Prevent-only classes are stopped before dispatch when possible: commit hook rejection in gate0, runconfig snapshot failures, missing registry auth, low disk, base moved.

Run-fatal shortlist only:
	- `journal-corrupt`
	- `not-a-git-repo`
	- `plan-invalid`

Unknown failures are task-scoped and quarantined. Do not kill the run for unknown task errors.

Partial run semantics: if any task is quarantined, emit `run.done`, print landed/quarantined/skipped summary, and exit `4`. Exit `0` means no quarantines.
