# Goal

Implement the complete RememberStack library described by the binding designs
and requirements, following the build sequence in `plan/plans/roadmap.md` from
phase 0 through phase 8.

## Program organization

This is a double loop:

- The parent `pm_planner_dispatcher` layer owns the high-level program. Its
  planner maintains a compact phase/milestone plan, reviews child outcomes,
  accepts or reroutes them, and decides when the whole program is complete.
  Its dispatcher only transports the selected outcome into one typed child
  request.
- Each child runs `inner_outer_eval` and owns delivery of its scoped outcome.
  The child outer role creates and revises the delivery plan, decomposes the
  outcome into work packages or smaller leaves, reviews implementation
  evidence, and decides child completion. Inner executes one selected leaf at
  a time. Child eval roles provide optional observations.
- Directly spawned agents are dynamic delegates inside one attempt. They do
  not become loop layers or inherit completion authority.

The parent normally plans at the level of a roadmap phase or a coherent
cross-WP milestone, not an exact edit or one narrow WP. A useful parent outcome
has concrete deliverables and observable completion evidence while leaving
more than one reasonable leaf decomposition to the child outer role. Split or
combine phase work only when dependencies, evidence, or risk make that more
coherent, and record why.

`plan/plans/roadmap.md` and the phase files are the sequencing authority. The
child outer role resolves each selected phase/milestone against the applicable
WP rows, `Reads`, dependencies, entry gates, deliverables, and acceptance
criteria. Designs are binding. If implementation would require contradicting a
binding design, the child must surface a precise source-linked conflict and
the program must reconcile the design/decision/plan through a normal PR before
implementing around it.

## Delivery contract

- All repository changes land through branch → PR → required checks → merge.
  Every PR names the owned phase/milestone and the concrete WP or leaf work it
  delivers. After merge, update the shared checkout to current `main` without
  discarding unrelated work and record the observed commit/PR/check evidence.
- The delivery child that owns work updates the corresponding phase-file WP
  statuses and exit evidence in the same PR. The parent records acceptance in
  its own state; it does not edit child implementation status on the child's
  behalf.
- Required CI—Ruff, Pyright, pytest, coverage, and any package/site checks
  applicable to the change—must be green before acceptance. User-facing
  behavior updates the public website documentation in the same PR.
- The library boundary in D60/D61 and the implementation rules in
  `CLAUDE.md` and `implementation_core_values.md` remain binding throughout.

## Evaluation as evidence

Evaluation informs the orchestrators; it does not own completion.

- A child may create or run outcome-focused session checks when they would
  materially improve confidence. Scheduled eval roles are visible in the
  workflow roster, so outer should consider their upcoming work before
  duplicating it. Missing, failed, stale, or conflicting evals are evidence to
  weigh and repair, not an automatic stop.
- The curated design-conformance inventory at
  `plan/implementation_evals/eval_checks/` is the prepared overall final review
  for the complete system. It is intentionally unsuitable as a per-WP progress
  bar because absent subsystems fail by design.
- Near final closeout, the parent planner must snapshot the complete current
  curated inventory, run it against the integrated current `main`, record the
  exact report and provenance, and resolve or explicitly weigh every material
  finding. The planner may use different enabled harness families in parallel
  to review check coverage and the results. Passing observations are strong
  evidence, but the planner remains accountable for the final reasoned
  completion decision.

## Completion criteria

The parent planner may declare the program complete when it has enough durable
evidence to conclude all of the following:

- Every phase from 0 through 8 has delivered its binding scope; its work
  packages and exit criteria are recorded as done with verifiable evidence.
- Phase 8 benchmark exit criteria have run successfully and their results are
  recorded.
- The complete current curated eval inventory has been run near final
  closeout, and every material result has been fixed, reconciled, or explicitly
  accepted with a defensible reason.
- Required CI is green on current `main`, and every repository change created
  by this program is represented by a merged PR. Historical branches outside
  this program are irrelevant.
- The parent plan, finished ledger, current state, decisions, and semantic
  handoff link enough phase, eval, git, PR, CI, and merge evidence for a cold
  reviewer to verify the conclusion without reconstructing the whole run.

Before `goal_met`, the planner updates those records and publishes
identity-bound protocol-v3 control with truthful evidence and optional accepted
eval references. A child completion never completes the parent automatically.

## Recovery and blockers

Failure is normally new planning input. A failed child, a weak eval, an
architectural conflict, or a blocked work package should lead to repair,
re-scoping, rerouting, or progress on an independent outcome. Owner-only
authority, unavailable credentials, legal clearance, or unauthorized
billable/destructive actions are never guessed. Only when a genuinely terminal
remainder cannot be avoided after all autonomous routes are exhausted may the
accountable layer use Loopy's D5 `unresolvable_error` escape hatch.

The repository already contains some foundation/scaffold evidence. The first
planner attempt should reconcile the high-level phase plan with current `main`
before selecting a milestone; it should not assume stale phase status is true,
and it should not dispatch a one-off “plan reconciliation” command as the
parent goal. Reconciliation is part of planning the first coherent phase
outcome.
