Dashboard/PRISM/Architecture/software-building-engine.md
PRISM

Architecture/software-building-engine.md

Software Building Engine

Concept

If every PRISM module follows the same pattern (config + playbook + schema), then building a module is a well-defined, repeatable task. Well-defined repeatable tasks can be automated by agents.

The Engine

ARCHITECT (Human + Claude brainstorming)
  │ Produces: module spec, playbook draft, schema requirements
  ▼
DISPATCHER (PM Agent)
  │ Reads TODO list, assigns tasks, tracks progress
  ▼
DEVELOPER AGENT ◄──► QA AGENT
  │                    │
  │ Follows:           │ Follows:
  │ - CodingSOPs       │ - TestingSOPs
  │ - Manifesto        │ - Schema contracts
  │ - Module pattern   │ - Golden fixtures
  │                    │
  │ Produces:          │ Produces:
  │ - config.py        │ - test_schemas.py
  │ - schemas.py       │ - test_playbook.py
  │ - playbook.md      │ - fixtures
  │ - executor glue    │ - pass/fail report
  │                    │
  └────── Loop until QA passes ──────┘
                │
                ▼
        VERIFIED MODULE
        Ready to deploy

Execution Plan

  1. Phase 1: Build intel-company v2.0 by hand using the unified module architecture. Prove the pattern works. Validate that playbook + schema + executor produces better results than the current implementation.

  2. Phase 2: Use the proven intel-company v2.0 as the template. Build the Developer Agent whose job is: "Given a module spec (playbook + schema + config requirements), produce a module that follows this exact pattern." The template IS the intel-company module.

  3. Phase 3: Build the QA Agent whose job is: "Given a module's schema and playbook, write tests that verify schema validation, playbook execution, citation quality, and merge strategy."

  4. Phase 4: Build the Dispatcher Agent that reads the TODO list, assigns modules to Developer + QA pairs, and tracks progress until all modules are built and tested.

Why This Works

  • The unified module pattern makes module creation TEMPLATABLE
  • The Pydantic schema makes testing CONTRACTUAL (the spec IS the test)
  • The playbook format is standardized (the Developer Agent knows exactly what to produce)
  • CodingSOPs and TestingSOPs are documented (the agents have clear standards to follow)

Why Phase 1 First

  • Can't build a factory for a product that hasn't been proven
  • intel-company v2.0 will reveal edge cases in the executor, playbook format, and merge strategy
  • Those learnings feed into the Developer Agent's knowledge base
  • Building by hand first = understanding the work deeply enough to automate it