Pstack Perform

The Core Rule

Ship it. Fix it. Ship it again.

The build-test-learn cycle is faster than the plan-build-test cycle. You learn more from a day-old prototype that broke than from a three-week build that never met the real world.

When to Run

• After Decide has chosen a path
• After Prune has confirmed the scope is right
• When you have a clear brief from Portfolio (what to build, what assumption to test)

The Perform Protocol

Step 1: Define Done

Minimum viable output: [the thing that proves it works — no more than this today]
Stretch goal: [what you'd add if everything went perfectly]
Time budget: [1 day / 2 days / end of sprint]
Definition of done: [what "it works" actually means — testable, not feels-like]

Step 2: Build the Minimum First

Start with the core loop — the thing that proves the concept. No features. No polish. No error handling worth speaking of. Just: does the key assumption hold?

Day 1:
├── Core logic working
├── Happy path end-to-end
└── One real test case

Day 2:
├── Fix what broke in Day 1 testing
├── Handle the obvious edge cases
└── Basic error states

Step 3: Integrate

Building in isolation is the most expensive mistake in software development. The Build Agent's job is to make the thing work with the rest of the system, not just work in isolation.

Checklist:
□ Does it work with actual data (not mock data)?
□ Does it integrate with existing systems?
□ Does the output format match what the next phase expects?
□ Is there a clear API / interface for the next agent to use?

Step 4: Document for Handoff

The Build Agent ships to Progress. Document:

# Build Output — [Date]

## What was built
[One paragraph: what it does]

## What it replaced / what assumption it tests
[The link back to the Portfolio/Decide phase]

## How it works
[The simplest description of the architecture]

## How to test it
[Step by step — someone else should be able to verify it works]

## Known limitations
[What it doesn't do — be honest]

## What would you do differently
[Self-critique for the Learn Agent]

The "Something Will Replace It" Mindset

This is not fatalism — it's a design principle. When you assume replacement:

• You don't over-engineer edge cases
• You document just enough for the next person (who might be future-you)
• You build interfaces that make replacement possible, not integration that creates lock-in
• You focus on the thing that matters most and leave the rest

The Observer Hook

The Build Agent's self-critique feeds directly to Observer. Every build teaches the Pod something about itself.

Portability

Works with any agent that can:

• Write code / execute scripts / call APIs
• Work with files and file systems
• Time-box and prioritize

Build Agents can work in parallel on different parts of the same sprint. Coordinate via shared files.