Milestone timeline
Generated from the repository's own records. An implementation report is evidence of work that shipped; a design document is a proposal and is always shown as planned, never as complete.
pipeline for the ANDY engine. It is not gameplay reconstruction and introduces no new game mechanics.
Verdict: Design proposal — not implemented
completes the engine's own documented Stage-2 milestone (`PROJECT_ROADMAP.md` → "Milestone 2 — Data Foundation", `docs/50` Stage 2). No gameplay reconstruction, no mechanics, no balance, no content.
Verdict: Design proposal — not implemented
deterministic, read-only post-battle analysis. Established from the repository's own roadmap (docs/50 Stage 3 first item; docs/29 §4–7), audited, and explicitly operator-approved including the deterministic rule set as NEW DESIGN.
Verdict: NEW DESIGN — POST-M50 / STAGE 3 BASIC INTELLIGENCE (first unit)
read-only ability-usage analytics. Established directly from the surviving specification (docs/29 §11 "Ability Usage Analysis"; docs/21 §10 "Ability Analytics"); every implemented metric is spec-named, so no new-design approval was required beyond the unit authorization.
Verdict: Design proposal — not implemented
read-only decision analytics. Established directly from the surviving specification (docs/21 §7 "Action Statistics"); every implemented metric is spec-named, so no new-design approval was required beyond the unit authorization.
Verdict: Design proposal — not implemented
read-only career performance analytics. Established directly from the surviving specification (docs/21 §6 "Combat Performance Statistics"); every implemented metric is spec-named and recorded, so no new-design approval was required beyond the unit authorization.
Verdict: Design proposal — not implemented
read-only, developer-controlled validation gate. Established directly from the surviving specifications (docs/50 Stage 4 "Every update must pass validation before becoming permanent knowledge"; docs/19 §12 "Training Data Validation"; docs/42 §3 "Data Validation" pipeline stage). Implemented under explicit user…
Verdict: Design proposal — not implemented
authorized write path behind the Stage 4.1 gate. Implemented under the user-approved bounded D-R005 contract (discovery audit → exact five-point authorization). No expansion beyond that contract.
Verdict: Design proposal — not implemented
admin-only inspection of the learning records Stage 4.2 persists. Selected by a fresh Stage-4.3 discovery audit (re-read from the surviving specs, not memory); no D-R005 authorization required — the unit adds zero knowledge semantics; it presents stored columns verbatim.
Verdict: Design proposal — not implemented
admin-only correction path over the records 4.2 persists. Selected by a fresh Phase-1 discovery audit (re-read from the surviving specs);
Verdict: Design proposal — not implemented
single-record DETAIL view completing the Stage 4.3 summary listing. Selected by a fresh Phase-1 discovery audit; no D-R005 authorization required — the unit transcribes one stored row verbatim and invents no semantics.
Verdict: Design proposal — not implemented
view of the Stage 4.1 validation gate over the whole battle table. Selected by a fresh Phase-1 discovery audit; no D-R005 authorization required — the sweep aggregates EXISTING deterministic verdicts by arithmetic only.
Verdict: Design proposal — not implemented
Milestone 22 was to transition the verified release candidate (`dio_engine 0.14.1`) into the Replit production environment and validate it live. The milestone executed every step possible from this workspace and produced the complete Replit deployment package and operator handoff. The live deployment did not occur…
Verdict: C — DEPLOYMENT BLOCKED
("A — Build Calamity", 2026-09-02, Arena session) after the Calamity gate was adjudicated NEEDS USER DECISION (M29 §23.6 was the open item).
Determine whether any remaining concrete implementation-ready work exists after M50+ without inventing a historical M51+ milestone or unsupported gameplay/economy/progression systems.
Determine the next historically supported ANDY reconstruction work after M50+ without inventing unsupported milestone scope.
Per the task brief ("Do NOT implement gameplay systems yet"), the following were deliberately left unimplemented — invoking them fails loudly via `UnimplementedFeatureError` or disabled feature flags, never silently:
All seven final clarifications were implemented consistently across CombatState, BattleConfig, Action Resolver, Effect Resolver, Damage Pipeline, Curse Pipeline, Turn Engine, Hook Framework, Event System, and the RNG/replay/analytics data — no duplicate systems, no reinterpretation, no rebalancing.
The architecture for the game's registerable content was built on top of the existing Registry System and Combat Engine — no second registry, no second resolution system, no engine rebalancing. The milestone builds the *infrastructure*; production content population, prototype migration, the Discord UI, and AI remain…
The production content layer was populated from the existing project specification (the preserved prototype, which documents names, descriptions, mechanics, and values) and the character/build persistence layer was built. Per the milestone rules, no content was invented: items whose mechanics cannot be expressed in the…
Milestone 5 was an audit-and-design milestone. The repository was read in full (context docs, DECISIONS/KNOWN_ISSUES/TASKS/ROADMAP, engine, registries, content modules, CharacterService, database, migrations, events, hooks, statuses, damage/healing, turn/action, RNG, tests, and the prototype). The baseline was…
Milestone 6 ports the documented legacy content — 79 Abilities and 41 Artifacts from the preserved prototype (`src/dio_engine`, the existing project specification per D-300) — into the production combat engine through a dedicated HOK-001 adapter, extending the engine only where the ported content demonstrably requires…
Milestone 7 finishes the combat foundation as far as the available authoritative information allows. It resolves every issue that can be safely resolved from the project specification and the preserved prototype (the authoritative content source, D-300), implements the engine capabilities the content actually requires,…
Milestone 8 finalized everything that could be safely finalized and prepared the Ultimate system for informed user approval.
slash commands, no button interface, no AI, no analytics, no matchmaking, no deployment.
AI, no analytics, no matchmaking, no deployment.
AI/analytics/matchmaking/ranking/economy.
instruction with real credentials).
matchmaking/ranking/economy/AI/analytics.
matchmaking/ranking/economy/AI/analytics.
Milestone 15 performed the definitive audit of every remaining incomplete Divine Ability, Artifact, and Consumable; implemented every mechanic that is sufficiently specified by the authoritative legacy source AND expressible in the production architecture; documented everything that cannot be safely implemented; and…
Milestone 16 is the decision-resolution and final Divine combat-specification lock. The M16 brief granted no approvals of the M15 decision package (M15-UD-01..08), so per the decision gate (M16 §2/§8) nothing was implemented that required authorization: no new engine capability, no content change, no rebalance. The two
Milestone 17 is the final decision-resolution and remaining-engine-gap milestone. The M17 brief granted no approvals of the M15 decision package (M15-UD-01..08) and did not address M16-AUD-002, so per the decision gate (M17 §2/§3/§9-§17) no authorized mechanic was implemented: no new content, no new engine capability,…
answered all nine gate questions; five were implemented, four were rejected/kept, and the standing deferrals/prohibitions were preserved.
Milestone 19 is the Human Content phase. The authoritative Human content source was located and read first: the legacy `classes/` package (25 classes across 4 tiers) and `class_engine.py`. The audit established that the class system IS the Human content — the legacy contains no Human abilities, artifacts, affinities,…
Milestone 20 performed the final whole-project audit: repository → engine → content → services → database → Discord → production configuration. The complete baseline was re-verified green, every audit dimension of the brief was exercised (lifecycle edges, serialization, determinism, isolation, security, CLI, production…
Verdict: B — COMPLETE WITH DOCUMENTED NON-BLOCKING LIMITATIONS
Milestone 21 executed the pre-deployment verification and infrastructure discovery for the controlled production launch. Every gate that can be run without external infrastructure passed: the full test suite, coverage, mypy strict, Ruff, build, migrations (idempotent), registry, readiness, bot dry-run, prototype fuzz,…
Milestone 22.5 renamed the project identity from DIO to ANDY across the user-facing repository surface while preserving every technical compatibility contract. Public branding now says ANDY: README, current-state documentation, CLI descriptions, the `dio check` app line, Dockerfile comments, the Replit packaging…
Verdict: B — COMPLETE WITH DOCUMENTED COMPATIBILITY IDENTIFIERS
Milestone 22.6 produced the actual, verified, transferable release archive for ANDY v0.14.1 and the complete operator handoff set. The archive `release/ANDY_Replit_Release_v0.14.1.zip` physically exists (1,202,476 bytes), contains the full project (364 files, 53 directories) with `ANDY_Replit_Release_v0.14.1/` as its…
Verdict: A — RELEASE PACKAGE READY
M23 audited the 16 proposed Runes against the actual repository and the Rune design rules (Appendix K as quoted in the milestone brief). The audit is audit-only: no Rune was registered, activated, or made canonical; no production behavior changed; no engine capability was added.
Verdict: B — AUDIT COMPLETE / MIXED DECISION PACKAGE
M24 implemented the approved Human Rune system end-to-end: 16 Runes as an Artifact subtype with `raid_exclusive` + RuneMaster access control, Bonded/Unbonded tiers, bound-curse interaction (via clean extension points), the approved acquisition model (solo 10% / group 1% / one group roll / anti-duplicate), a PvP reward…
Verdict: COMPLETE
The approved change is implemented: the Light Rune's restriction is now represented as a Rune-level eligibility rule declared on the Rune itself, replacing the representation in which Light Rune eligibility was emergent from a generic class-level flag (the raid-exclusive / `grants_raid_artifact_access` mechanism…
Verdict: COMPLETE
M28 restructured the player-facing command and battle interaction architecture: fewer commands → more buttons/selects → clearer embeds → easier information access. Six per-type information commands were consolidated into one `/info` command with eight selectable categories; the battle is now driven by eight primary…
Verdict: A — COMMAND/UI RESTRUCTURE COMPLETE
All 32 collisions (28 abilities + 4 artifacts) have a thematic Human canonical name; the Divine originals are untouched; `source_name` is preserved in metadata. Implemented in this milestone:
Verdict: COMPLETE — Human ecosystem functionally implemented (with precisely documented deferred items)
Implemented, per the M30 brief: 1. 16 Human Affinity identities (identity-only — the source establishes no affinity mechanics). 2. 16 Human player Curses with source-derived mechanics where the engine supports them. 3. `HUMAN_AFFINITY_CURSES` — the authoritative Human Affinity → Curse mapping. 4. Reconciliation of all…
Verdict: A — COMPLETE (with documented blockers for 2 curse effects and 1 deferred Rune effect)
The bosses are Divine beings (`content_race="divine"`, no class) whose stats come from the existing battle service stat generation (`_stats_for` → `allocate_hp_power`); the 5× endgame-Divine baseline is achieved by creating the battle with `cumulative_stats = 5000` (vs the default 1000) — the spec's multiplier through…
Verdict: COMPLETE — all seven Sins implemented with unique Divine Laws, deterministic behavior, focused tests, and no existing-mechanic regressions.
M31.0 creates *only* the foundation the later M31 stages build on:
Verdict: COMPLETE — foundation layer implemented; every content id now renders as a registry display name on player surfaces; B3 made safe, B5 fixed; 52 new tests; suite and all quality gates at or above baseline. Later stages (M31.1+ interaction work) intentionally NOT started.
M31.4 reuses the M31.0 command synchronization implementation. No duplicate `tree.sync()` path was added.
Reconstruct and verify the supported Human consumable anchor without inventing economy, prices, ownership quantities, crafting, unlocks, or progression.
M34–M37 exact historical objectives were not recovered. - Existing reconstructed systems have explicit safety needs around ownership, stale interactions, idempotency, NameResolver usage, and presentation consistency. - M40 will need cosmetic-only integration seams, but M40 itself is not part of this batch. - Existing…
Reconstruct the evidence-backed Character Customization layer as a cosmetic-only system using existing persistence seams.
`ui_reference_text.txt` references `/list`, `/info`, `/list ability`, `/list artifact`, artifact rarity grouping, and `/craft`. - `MILESTONE_RECONSTRUCTION_ROADMAP.md` classifies M41–M49 as UI/content catch-up. - Existing `/info` architecture already existed and was retained. - M32–M33 verified supported Human content:…
The existing reconstructed functional systems remain authoritative:
Content shipped
What the registry loads today, by content type.