Engineering Board

Connect findings. Inspect the evidence.

Repository memory for engineering agents.

_The board is the memory. Markdown is the record._

Explore the example · Start with Codex · Open the real project board

Validation evidence and real project board

_This visual shows deterministic fixture output for the pattern pipeline._

_These visuals retain their recorded validation facts; they are not current product-effect claims._

Product description

Engineering Board is a repository-owned pattern-intelligence system for engineering agents.

The system records bugs, features, questions, and observations as Markdown evidence. It connects recurring findings in a deterministic graph.

The graph helps an agent investigate a shared cause across different domains. This method reduces repeated corrections of individual symptoms.

Markdown is the canonical record. A pull request can show each change to this record.

BOARD.md, GRAPH.yml, JSON analysis, and HTML are derived views. The system can build these views again from the canonical record.

A hypothesis is separate from a deterministic graph fact. Only investigation evidence or fix evidence can confirm a hypothesis.

The optional tdd → review → validate loop can test a fix. This loop supports the pattern memory, but it does not define the product.

Milestone C adds:

• A transparent investigation score from 0 through 100
• A durable H### hypothesis lifecycle
• Negative memory for a rejected claim.

Each score component is visible. A score does not prove that a cause is true.

Milestone D puts this memory in the agent's decision path:

• board_context retrieves relevant clusters, hypotheses, negative memory, and Learnings before the agent selects a fix.
• Each result shows a stable title, a typed summary of at most 2,000 characters, the epistemic state, structural signals, score components, match reason, and canonical sources.
• board_get_entry opens a retrieved H### record in full, including its alternatives and falsifier. Reading preserves its status; it does not confirm a proposed cause or record an outcome.
• A task-only miss tells the caller to add a file, entry identifier, or current directory. Task words do not bypass structural eligibility.
• board_outcomes records an explicit fix result against an H### hypothesis.
• Structured outcomes update Learning state and confidence through a separate preview and apply operation.
• A derived value report counts verified reuse and systemic fix evidence. It does not count prompts, sessions, or other activity.

Milestone D.1 adds a repository-only evaluation harness and eight sanitized cases. The default contract prepares 24 isolated baseline/context pairs for a Codex reference run. Other clients can run as optional replications without changing the product gate. Protocol and package tests establish supported client surfaces without requiring provider accounts. The first Codex run scored 100 percent in both positive baseline and context arms, so the corpus was retained as a non-scored calibration set. A separate locked evidence corpus excludes declared scoring oracles and requires rejected memory in its lexical-decoy contexts. Its reference run scored 100 percent for context and 83.33 percent for baseline. The 16.67-point difference did not meet the required 25-point improvement. The project does not claim that the context improves agent diagnoses.

The unlocked version 4 proposal now limits each positive case to one visible current incident. It also requires a positive classification to connect that incident to prior repository evidence. A non-scored proposal preflight found that v1.11.0 ranks the expected memory but does not include the memory title, cause, or summary in the returned result. Context contract version 2 added that bounded canonical content with its separate epistemic state, match reason, and sources. Current contract version 3 preserves those limits and adds confidence for moment-of-need Learning delivery. A current-source, one-repetition preflight then produced zero qualifying cross-incident first causes in both the four baseline arms and the four context arms. The expected memories ranked first or second, but the responses did not connect their current incident to the prior incident. This is not a scored product-effect result. A later source-locked C04 diagnostic tested raw JSON versus shipped prompt-guard prose, each before and after case evidence. All four treatments again produced current-incident-only first causes, so presentation format and position are not sufficient for C04 under that bounded current-client test. The proposal remains unlocked, and the exact baseline decision remains with the product owner. See evaluation/README.md for the proof boundary and operator commands.

Product differences

Some Git boards show visible state but have little analysis. Some memory systems have useful analysis but keep the source outside the repository.

Engineering Board combines these properties:

• Repository evidence that a pull request can review
• A cross-domain pattern graph with evidence links
• H### records with alternatives and falsifiers
• Negative memory for rejected claims
• Atomic claims for parallel agents
• Passive capture
• Codex and Claude Code plugins
• An MCP server.

Native Claude Code Tasks and Engineering Board have different purposes.

Native Tasks store personal task state in ~/.claude/tasks/. This state is not part of a project pull request.

Engineering Board stores shared project memory in the repository. Use Native Tasks for temporary personal work. Use Engineering Board for durable project knowledge.

Install the Codex plugin

Add the repository marketplace:

codex plugin marketplace add GhostlyGawd/engineering-board

Install the plugin:

codex plugin add engineering-board@engineering-board

The Codex marketplace installs the repository root from the immutable Git tag that matches the advertised plugin version. Refresh the marketplace before installing a newer released version.

Start a new Codex session. The plugin supplies five board skills and starts the 19-tool Engineering Board MCP server. It does not require a model-provider account. The Codex manifest explicitly selects hooks/codex-hooks.json, which contains no automatic hooks. Codex therefore uses the skills and MCP server without loading the Claude Code hook workflow from hooks/hooks.json.

Ask Codex to initialize Engineering Board in the active repository. The agent passes the absolute repository root to board_init and uses the MCP tools for capture, promotion, context, graph, hypothesis, outcome, claim, and lifecycle operations.

Install the Claude Code plugin

Add the repository marketplace:

/plugin marketplace add GhostlyGawd/engineering-board

Install the plugin:

/plugin install engineering-board

Set up a board:

/board-setup

/board-setup creates the board structure. It also checks the required permissions.

Run the contained demonstration:

/board-demo

The command creates a synthetic run in .engineering-board/demo/pattern-intelligence/.

The command connects three findings from different domains. It then requests one hypothesis that cites the evidence.

The hypothesis has status: proposed. It includes an alternative explanation and a falsifier.

The report gives an exact cleanup command. The cleanup operation preserves a changed run.

For explicit setup values, use:

/board-init <project> [affects-prefix]

/board-install-permissions

Use the pattern-memory workflow

With Codex or another MCP client:

1. Initialize one project with board_init.
2. Retrieve relevant memory with board_context before selecting a fix.
3. Capture findings with board_capture_finding.
4. Preview and apply promotion with board_promote_findings.
5. Use board_insights and board_hypotheses for evidence-linked shared-cause analysis.
6. Record the observed result with board_outcomes.

Pass the absolute repository root in each bundled-plugin tool call. The plugin does not guess which open workspace a raw MCP call targets.

With Claude Code hooks and commands:

1. Work in Claude Code.
2. Let SessionStart and UserPromptSubmit retrieve relevant systemic memory.
3. Run /board-context when you want the same bounded brief explicitly.
4. Read the memory title, typed summary, epistemic state, match reason, and sources. Inspect the cited canonical record before you rely on a proposed cause.
5. In PM mode, read the matched medium/high-confidence Learnings appended to the pass summary after new findings promote.
6. Let the Stop hook capture a finding in engineering-board/ /_sessions/.
7. Run /board-promote to preview canonical changes.
8. Apply the unchanged promotion plan after you review it.
9. Run /board-insights when you need the complete ranked investigation view.
10. Run /board-hypothesis propose to preview an H### record.
11. Review the evidence, alternative, counter-evidence, confidence basis, and falsifier.
12. Apply the unchanged hypothesis plan.
13. After verification, run /board-outcome preview ....
14. Apply the unchanged outcome plan. Review and apply each returned Learning plan separately.

An outcome records held, failed, `partia