Ingest.Implement

---
description: "Phase 4: Launch implementation agents. Single agent for LOW/MEDIUM, layer-by-layer waves for HIGH."
---

# Ingest — Phase 4: Implement

Two execution modes based on complexity routing from Phase 3.

## Configuration

```yaml
DB_CONN: "host=dev02.brown.chat dbname=contextpalace user=penfold sslmode=verify-full"
CP_CLI: cp
MAX_RETRIES: 3

Agent Context Requirements

Every implementation agent MUST read the project context docs before starting work. Include these instructions in every agent prompt:

## Setup (MANDATORY — do this before any code changes)
1. cxp knowledge show mycroft-dev-index — project architecture, conventions, patterns
2. cxp knowledge show mycroft-agent-<agent-type> — your domain-specific context
3. Read your assignment: cxp task get pf-xxx
4. Claim the work: cxp task claim pf-xxx

Coding Standards (Include in All Prompts)

Include these standards in every implementation agent prompt:

## Coding Standards
- Error handling: Return errors up the call stack. Use fmt.Errorf("context: %w", err) for wrapping.
  Do NOT log and return — either log OR return, not both.
- Logging: Use structured logging (slog). Include relevant IDs (tenant_id, content_id, entity_id).
- Naming: Follow existing codebase conventions. Check nearby files for patterns.
- Comments: Only where the logic isn't obvious. No redundant comments on clear code.
- Tests: Table-driven tests preferred. Test happy path + error cases + edge cases.
- Imports: Group stdlib, external, internal. Use goimports formatting.
- API stability: Do NOT change existing function signatures. If you need additional parameters,
  add them with defaults, create a new function, or use an options struct. Changing a signature
  cascades to all callers and wastes context fixing compile errors.

Context Budget Warning (Include in All Prompts)

Include this in every implementation agent prompt:

## Context Budget
You have a limited context window. Prioritize in this order:
1. Complete the implementation (working code that compiles)
2. Make all tests pass (both pre-existing and new)
3. Clean up (formatting, comments, imports)

If you are running low on context:
- STOP adding features. Finish what you have.
- Ensure go build passes.
- Close the shard with a progress note: "Implemented: [what's done]. Remaining: [what's left]."
- Do NOT defer tests — if you can't write tests, say so explicitly in the close message.

BAIL-OUT RULE: If you hit cascading compile errors (e.g. a signature change broke 5+ callers),
STOP immediately. Do NOT grind through fixing caller after caller. Instead:
- Revert the signature change
- Find a backwards-compatible approach (add new function, use defaults, options struct)
- If you cannot find one, close the shard with: "BLOCKED: [explanation]. Needs orchestrator guidance."

---

Implementation Loop

Two retry mechanisms, depending on execution mode:

Mode: Dispatched Sessions (Agent Factory)

When work is dispatched as a standalone Claude session (via dispatch-agent or the poller), use the ralph-loop plugin for session-level retry:

/ralph-loop "Run /ingest.implement pf-XXX. Follow it exactly. Output <promise>DONE</promise> when complete, or <promise>BLOCKED</promise> if stuck." --max-iterations 5 --completion-promise "DONE"

The stop hook blocks session exit and re-feeds the prompt. Each iteration sees the previous attempt's file changes and can course-correct with full context.

Mode: Sub-Agent (Orchestrator Retry)

When launched as sub-agents via the Task tool (current model), the orchestrator manages retries externally. Same prompt, fresh context, persistent code changes.

Why this matters: Sub-agents that fail on the first attempt have already modified files. A fresh sub-agent sees those changes, plus the error output from the previous attempt, and can course-correct with a full context window. This is fundamentally better than retrying within a depleted context.

Loop logic (applied to EVERY sub-agent):

for attempt in 1..MAX_RETRIES:
    launch sub-agent (fresh context)
    wait for completion

    ## TWO-SIGNAL VERIFICATION (both must agree)
    # Signal 1: Independent build/test check (PRIMARY — ground truth)
    run: go build ./path/to/... && go test ./path/to/... -v
    # Signal 1b: If Penfold acceptance test exists, run it too (must also pass)
    run: go test -tags=quality -run TestQuality/NNN ./tests/quality/ (or e2e equivalent)
    # Signal 2: Shard close reason prefix (SECONDARY — agent's self-report)
    read shard close reason

    # Classification:
    if build+tests PASS and close reason starts with "DONE:" → SUCCESS, break
    if close reason starts with "BLOCKED:" → ESCALATE to penfold immediately, break
    if build+tests FAIL (regardless of close reason) → FAILED, enter retry
    if build+tests PASS but close reason is not "DONE:" → treat as SUCCESS with warning
        (log: "Agent used non-standard close prefix. Verified independently.")

    # Retry path:
    if attempt < MAX_RETRIES:
        capture: build errors, test failures, close reason
        re-open shard: cxp task reopen pf-xxx
        add progress note:
          cxp task progress pf-xxx "Attempt [N] failed: [error summary]. Retrying with fresh agent."
        continue loop
    else:
        ESCALATE to penfold — all retries exhausted

Why two signals: Sub-agents may use non-standard prefixes ("Completed:", "Implemented:"). Build and test results are ground truth. The close reason is useful context for retries but should never be the sole determinant of success or failure.

Retry prompt additions: When re-launching (attempt > 1), prepend this to the sub-agent prompt:

## RETRY CONTEXT — Attempt [N] of [MAX_RETRIES]

Previous attempt failed. The previous agent's code changes are already in the files.

**Previous failure:**
[paste closed_reason or error output from previous attempt]

**What to do:**
1. Read the files t