Modernize SmokedMeat through behavior-preserving architecture iterations

[fproulx-boostsecurity]

Purpose

SmokedMeat works, but rapid behavior-first development has left accumulated duplication, dead code, shallow modules, unclear ownership, and tests coupled to incidental implementation details. This program provides a deliberate path for gradually modernizing the codebase without turning the work into an open-ended rewrite.

Destination

Modernize SmokedMeat through a sequence of bounded, behavior-preserving architecture deepening iterations. Each iteration should leave one important area easier to understand, test, and change while keeping the operator experience and supported behavior stable.

Guardrails

• Preserve Counter UX and fundamental product behavior unless a separate product decision explicitly changes them.
• Correct accidental defects exposed by an iteration rather than preserving them as compatibility requirements.
• Tackle one high-leverage module or closely related cluster per iteration.
• Use the domain language in CONTEXT.md and the architecture vocabulary of module, interface, depth, seam, adapter, leverage, and locality.
• Apply the deletion test. A refactor should concentrate complexity and remove obsolete paths, not add another layer beside them.
• Treat the module interface as the test surface. Characterize behavior before changing ownership or structure.
• Remove dead code, duplicate implementations, stale tests, and cruft exposed by the iteration.
• Record durable, hard-to-reverse decisions as ADRs.
• Verify the smallest affected behavior first, then widen checks according to cross-package, persistence, process, and operator-flow risk.
• Avoid a big-bang rewrite. Every iteration must be independently reviewable and leave the product working.

Operating model

Native child issues, their state, their dependency relationships, and their project status are the canonical record of completed, active, and planned program work. Read them before acting. Do not duplicate their status or history in this description.

• Continue an active child iteration before starting a competing one.
• Use open, unblocked work to determine the next action within an active iteration.
• Treat closed child issues as program history and existing open child issues as already planned work.
• When no active or planned iteration remains, run $improve-codebase-architecture to inspect recent hot spots, CONTEXT.md, relevant ADRs, nearby code, and tests for the next evidence-backed deepening opportunity.
• Present the architecture candidates visually and let the maintainer select one before proposing its interface.
• For a selected opportunity that is too large or uncertain for one implementation session, create a Wayfinder map as a native child of this program and resolve its decision frontier before implementation.
• Do not pre-list speculative future iterations here. Discover them from current code and tracker evidence when the frontier reaches them.

Iteration lifecycle

1. Discover and select an evidence-backed deepening opportunity when the tracker shows that no current iteration remains.
2. Establish the domain terms and existing ADR constraints.
3. Resolve the necessary architecture decisions through a Wayfinder map when the route is not already clear.
4. Implement in coherent slices, replacing old paths instead of layering permanent parallel implementations.
5. Verify behavior, persistence, concurrency, and operator flows in proportion to risk.
6. Close the iteration with obsolete code removed and remaining uncertainty routed into a later map or roadmap candidate.

Program completion

This program is successful when repeated iterations have made SmokedMeat materially easier to navigate, test, and evolve without destabilizing the tool operators already use. Each child iteration remains independently completable; this issue tracks the continuing modernization direction rather than one monolithic delivery.