30 KiB
30 KiB
Cross-Document Coherence Audit — V2 Migration Pre-Flight
Date: 2026-02-23
Auditor: Auditor (Subagent)
Documents Reviewed: 5 source document sets, 48 AOM docs (sampled), 4 pillars
Scope: Pre-migration alignment verification for Atomizer V2 migration
Executive Summary
VERDICT: CONDITIONAL PASS — Proceed with Cautions
The V2 migration can proceed, but not as-is. Three critical contradictions and five major gaps require resolution before Phase 1 execution. The documents are directionally aligned on architecture and tool strategy, but they diverge on:
- Contracts implementation timing (contradictory)
- Project Standard integration scope (under-specified in Arsenal V3)
- Structural path definitions (contradictions between Arsenal V3 and Migration Plan V3.1)
Top 3 Findings
| # | Finding | Severity | Impact |
|---|---|---|---|
| 1 | Contracts deferral conflict: Arsenal V3 says "contracts are canonical in architecture doc," Migration Plan V3.1 says "stubs only at P0, implement post-migration" — Architecture doc says "contracts are NEW" (not existing). This creates a circular dependency. | 🔴 CRITICAL | Phase 1 cannot implement contracts that don't exist yet |
| 2 | Project Standard orphaned in Arsenal V3: Migration Plan V3.1 added full Project Standard integration (§5.5, templates/, init script) as P1 deliverables. Arsenal V3 Final (the architecture source) doesn't mention Project Standard at all — no templates folder, no init script, no study paths at 03-studies/. |
🔴 CRITICAL | Arsenal V3 is not the complete architecture — migration plan adds 15+ deliverables not defined upstream |
| 3 | NX consolidation path mismatch: Arsenal V3 says atomizer/processors/geometry/nx_geometry.py, Migration V3 says atomizer/nx/ as consolidated NX home with journals/ subdirectory. Both are present in V2 structure tree but with different organizational philosophies. |
🟡 MAJOR | NX code may be split across two locations creating maintenance confusion |
Recommendation
APPROVE migration with mandatory pre-Phase-1 actions:
- Resolve contracts chicken-and-egg: Either (a) write contract stub definitions NOW in architecture doc before migration starts, OR (b) accept that contracts are post-migration work and remove all P0/P1 references to implementing them
- Backport Project Standard to Arsenal V3: Update Arsenal V3 Final (the canonical architecture) to include Project Standard as a first-class component with templates/, init script, and engine --project-root support
- Consolidate NX strategy: CEO decision: Is NX a processor alongside others (
processors/geometry/nx_geometry.py) OR is it a special legacy subsystem (nx/with all NX code consolidated)? Both structures exist in the plan — pick one.
With these three corrections, the migration is sound and executable.
A. Structural Alignment
Question: Does the V2 repo structure in the migration plan match what Arsenal V3 defines?
Alignment ✅
| Component | Arsenal V3 Final | Migration Plan V3.1 | Status |
|---|---|---|---|
| Three-layer architecture | contracts/, processors/, orchestrator/ |
✅ Present in V2 tree | ✅ MATCH |
| Optimization engine | atomizer/optimization/ |
✅ Present | ✅ MATCH |
| Extractors | atomizer/extractors/ |
✅ Present | ✅ MATCH |
| Spec/config | atomizer/spec/ |
✅ Present | ✅ MATCH |
| Dashboard | dashboard/ |
✅ Present | ✅ MATCH |
| MCP servers | mcp_servers/ |
✅ Present (placeholder) | ✅ MATCH |
| Knowledge base | atomizer/knowledge/ |
✅ Present | ✅ MATCH |
Contradictions 🔴
| Item | Arsenal V3 Says | Migration Plan V3.1 Says | Resolution Needed |
|---|---|---|---|
| Contracts location | "Canonical in ATOMIZER-TOOL-AGNOSTIC-ARCHITECTURE.md Section 2.1" (Arsenal V3 §2.1–2.2) |
atomizer/contracts/*.py files in V2 tree (§2) |
⚠️ Problem: Architecture doc (from AOM review) says contracts are NEW design, not existing code. Arsenal says "don't duplicate dataclass definitions" but doesn't provide them. Migration says "stub → implement P1/P2" but Arsenal says "these are canonical already." CIRCULAR DEPENDENCY. |
| NX module organization | atomizer/processors/geometry/nx_geometry.py (Arsenal V3 §4.1 table) |
atomizer/nx/ with solver.py, session_manager.py, journals/, etc. (Migration §2, §3.7) |
⚠️ Arsenal treats NX as one processor among many. Migration treats NX as a special subsystem. Both exist in V2 tree. SPLIT PERSONALITY. |
| Project Standard templates | ❌ NOT MENTIONED in Arsenal V3 | templates/project/ + tools/init_project.py + engine --project-root flag (Migration §2, §3.17, §5.5) |
⚠️ Arsenal V3 is incomplete. Migration added ~15 files and integration work that Arsenal never defined. |
Gaps 🟡
| Gap | Arsenal Defines | Migration Implements | Missing Link |
|---|---|---|---|
| processors/base.py | Arsenal V3 §4.1: "Abstract base classes (NEW)" | Migration §2: atomizer/processors/base.py |
✅ Implied by Arsenal, implemented by Migration — no gap |
| orchestrator/pipeline.py | Arsenal V3 §4.1: "Main evaluation loop" (NEW) | Migration §2: atomizer/orchestrator/pipeline.py |
✅ Implied by Arsenal, implemented by Migration |
| Processor categories | Arsenal V3 lists: geometry/, meshing/, solvers/, postprocessing/, converters/, surrogates/ | Migration §2 has all 6 categories | ✅ Full alignment |
Naming Consistency ✅
Folder names, module locations, and component boundaries are consistent where both documents define them. The contradictions are about what's included, not what it's called.
Verdict for Section A: 🟡 MAJOR ISSUES
- Core architecture alignment is strong (3-layer model, folder structure, component names)
- Contracts and NX placement are contradictory
- Project Standard is a migration-only addition not backed by Arsenal
B. Project Standard Integration
Question: Does the migration plan properly implement the Project Standard's folder structure, entry points, KB architecture, and study lifecycle?
What the Project Standard Defines
From P-Atomizer-Project-Standard/05-FINAL-RECOMMENDATION.md:
| Requirement | Specification |
|---|---|
| Root structure | 9 top-level items: README, CONTEXT, BREAKDOWN, DECISIONS, models/, kb/, studies/, playbooks/, deliverables/ |
| Study numbering | {NN}_{slug} format (01_doe_landscape, 02_tpe_refined, etc.) |
| KB structure | 4 folders: components/, materials/, fea/, dev/ |
| Study lifecycle | 3 phases: Setup (human) → Execute (machine) → Review (human+machine) |
| Study internals | 1_setup/, 2_iterations/, 3_results/, 3_insights/ |
| Entry points | README.md (single entry, not PROJECT+AGENT+STATUS split) |
What Migration Plan V3.1 Implements
From Migration Plan §3.17, §5.5:
| Component | Migration Status | Location |
|---|---|---|
| Template files | ✅ ~14 .template files | templates/project/ |
| Scaffolding script | ✅ NEW script | tools/init_project.py |
| Engine integration | ✅ --project-root flag |
atomizer/optimization/engine.py, atomizer/study/creator.py |
| AOM reference | ✅ Pillar 2 cross-reference planned | docs/AOM/02-Operations/ |
Does Migration Match Project Standard?
| Project Standard Requirement | Migration Plan Implementation | Status |
|---|---|---|
| 9-item root structure | Template includes PROJECT.md, AGENT.md, STATUS.md, DECISIONS.md, CHANGELOG.md, 00-context/, 01-models/, 02-kb/, 03-studies/, etc. | ⚠️ MISMATCH: Standard recommends single README.md, not PROJECT+AGENT+STATUS split. Migration uses OLD spec structure (§9 of spec superseded by §5 final recommendation). |
| KB 4-folder structure | Template has design/ (5 branches), analysis/ (7 subdirs), manufacturing/, domain/, introspection/ | 🔴 CONTRADICTION: Standard says 4 folders (components/, materials/, fea/, dev/). Template has 5 branches with 15+ subdirs (the OLD rejected spec). |
| Study lifecycle | Engine integration supports --project-root, studies at 03-studies/ |
✅ MATCH |
| Study numbering | Standard: {NN}_{slug}. Engine: compatible |
✅ MATCH |
| atomizer_spec.json | Standard: per-study spec at study root. Engine: loads from study path | ✅ MATCH |
Critical Finding 🔴
The Migration Plan's Project Standard templates (§3.17 table) are based on the REJECTED SPECIFICATION (00-SPECIFICATION.md), NOT the APPROVED FINAL RECOMMENDATION (05-FINAL-RECOMMENDATION.md).
Evidence:
- Final Recommendation says: "README.md (single entry point, replaces PROJECT+AGENT+STATUS)"
- Migration template table lists: "PROJECT.md.template, AGENT.md.template, STATUS.md.template"
- Final Recommendation says: "KB 4 folders (components/, materials/, fea/, dev/)"
- Migration template structure shows: "design/, analysis/ with 7 subdirs, manufacturing/, domain/, introspection/"
The migration is implementing the WRONG standard.
Gaps 🟡
| Gap | Description |
|---|---|
| Template versioning | Project Standard spec §9 calls for .atomizer/template-version.json to track which standard version a project uses. Migration lists this file but doesn't specify version tagging strategy. |
| Migration script for existing projects | Standard discusses migrating Hydrotech Beam (~15 min effort). Migration plan doesn't include a migration helper for V1 projects to Project Standard structure. |
Verdict for Section B: 🔴 CRITICAL FAILURE
- Migration implements the rejected spec, not the approved recommendation
- Templates must be completely rewritten before Phase 1
- This affects ~15 files in the migration inventory (§3.17)
C. AOM Consistency
Question: Does the migration plan's documentation structure align with the AOM's 4-pillar organization? Would migration break AOM references?
AOM Structure (from MAP.md)
| Pillar | Docs | Purpose |
|---|---|---|
| 01-Philosophy | 9 docs | Mission, architecture, component map, tool-agnostic design |
| 02-Operations | 15 docs | Study lifecycle, protocols, specs, integrations |
| 03-Developer | 10 docs | Codebase, API, extension points, processor dev |
| 04-Knowledge | 6 docs | LAC, KB architecture, failure patterns |
Total: 48 docs (40 main docs + Audit/ + Phase-4-LLM-Layer/ + Phase-5-Living-Protocol/)
Migration Plan's AOM Deployment
From Migration §5:
docs/
├── AOM/
│ ├── README.md # MAP (renamed)
│ ├── 01-Philosophy/ # 9 docs
│ ├── 02-Operations/ # 15 docs
│ ├── 03-Developer/ # 10 docs
│ ├── 04-Knowledge/ # 6 docs
│ └── Audit/ # 2 docs
├── protocols/ # OP/SYS/EXT migrated from V1
├── QUICK_REF.md
└── guides/
Alignment: ✅ PERFECT 1:1 MAPPING
The migration preserves the exact 4-pillar structure. MAP.md → README.md rename is correct (Gitea auto-renders README).
Path Breakage Check
Question: Do any AOM docs reference V1 paths that the migration would break?
Sample from AOM docs reviewed:
- Component Map (§4) references
atomizer/contracts/,atomizer/processors/,atomizer/orchestrator/→ ✅ These paths exist in V2 structure - Tool-Agnostic Architecture (§8) describes the 3-layer model → ✅ V2 implements this exactly
- Arsenal Reference would reference MCP servers → ✅
mcp_servers/placeholder exists in V2
Potential Breaks:
| AOM Doc | Likely References | V2 Status | Risk |
|---|---|---|---|
| 02-Operations/09-NX-Integration | May reference optimization_engine/nx/ paths |
⚠️ V2 has atomizer/nx/ — paths changed |
🟡 Needs path updates |
| 03-Developer/01-Codebase-Architecture | Module dependency map | ⚠️ All optimization_engine.* → atomizer.* |
🟡 Needs update |
| 03-Developer/03-API-Reference | Import statements | ⚠️ Import paths changed | 🟡 Needs update |
| 04-Knowledge/02-Knowledge-Base-Architecture | May reference old knowledge_base/ |
✅ V2 has atomizer/knowledge/ |
✅ Compatible if relative |
Mitigation: Migration Phase 0 includes AOM link conversion (§5.1: convert [[wiki-links]] → relative MD links). This MUST also update any code paths in AOM docs from optimization_engine/ → atomizer/.
AOM Cross-References to Project Standard
Migration §5.5.4 says: "AOM Pillar 2 (Operations) references the Project Standard spec"
Gap: The AOM MAP.md reviewed does NOT currently mention Project Standard. The only reference is in Related Projects section pointing to P-Atomizer-Project-Standard/MAP.
Required action: During AOM deployment (Phase 0), add Project Standard guide to 02-Operations/ (e.g., 02-Operations/16-Project-Organization-Standard.md or update existing docs to reference templates/).
Verdict for Section C: 🟢 OK with Minor Updates
- AOM pillar structure perfectly preserved
- Path updates needed in 3–5 AOM docs (tracked in Phase 0)
- Project Standard cross-reference is a forward commitment, not a current contradiction
D. Contradictions Table
| Doc1 Says | Doc2 Says | Nature | Severity |
|---|---|---|---|
Arsenal V3 §2.2: "Contract dataclasses are canonical in ATOMIZER-TOOL-AGNOSTIC-ARCHITECTURE.md Section 2.1. Do not duplicate." |
Tool-Agnostic Architecture (AOM): Contracts are described as NEW design pattern. Section 2.1 lists what they should contain but doesn't provide Pydantic/dataclass implementations. | Contracts don't exist yet, but Arsenal references them as canonical source. | 🔴 CRITICAL |
| Arsenal V3 §2.2: "All contract details reference Section 2.1 above" (implying contracts are defined) | Migration V3.1 §2, Phase 1: "Create contract stubs (docstrings only, no implementation). DEFERRED to post-migration." | Arsenal says contracts exist. Migration says create stubs. Circular dependency. | 🔴 CRITICAL |
Arsenal V3 §4.1: NX listed as atomizer/processors/geometry/nx_geometry.py |
Migration §2 + §3.7: NX consolidated at atomizer/nx/ with solver.py, session_manager.py, journals/ |
Is NX a single geometry processor or a subsystem? | 🟡 MAJOR |
| Arsenal V3 Sprint 3 §5.3: "Topology Engineer (new)" activated Sprint 3 | Webster Review §4: "Topology is post-MVP future (Arsenal V3 §3.1). Role activation conflicts with scope boundary." | Topology Engineer exists in agent roster but topology is explicitly out of scope. | 🟡 MAJOR |
| Project Standard Final Recommendation: "README.md (single entry point)" | Migration §3.17 template table: "PROJECT.md.template + AGENT.md.template + STATUS.md.template" | Migration implements rejected spec, not approved recommendation. | 🔴 CRITICAL |
| Project Standard Final Recommendation: "4-folder KB: components/, materials/, fea/, dev/" | Migration §3.17 template structure: "design/ → analysis/ (7 subdirs) → manufacturing/ → domain/ → introspection/" | Migration uses OLD 5-branch spec rejected by final recommendation. | 🔴 CRITICAL |
| Arsenal V3 §3.1: OpenFOAM is "Expansion Stack (Sprints 4-6)" | Arsenal V3 §5.4: Sprint 4 delivers OpenFOAM lane | ✅ Self-consistent — expansion starts Sprint 4 | 🟢 OK |
Arsenal V3 §4.1: launch_dashboard.py listed in root |
Migration §2: dashboard/launch_dashboard.py |
Path moved — minor | 🟢 OK |
Summary: 3 critical contradictions, 2 major contradictions, 0 architecture-breaking contradictions (the core 3-layer model is fully aligned).
E. Gaps Table
Defined in Source, Missing from Migration
| Defined In | What's Defined | Missing From | Impact |
|---|---|---|---|
| Arsenal V3 §6 (Agent Roster) | 19 agents: Manager, Technical Lead, Optimizer, NX Expert, Post-Processor, Reporter, Study Builder, Auditor, Researcher, Developer, KB, IT, Meshing Engineer, CFD Specialist, Coupling Engineer, Topology Engineer, MDO Architect, MCP Engineer, Secretary | Migration Plan (repo structure) | 🟢 OK — agents are runtime entities, not repo structure. Migration doesn't need to define agents. |
| Arsenal V3 §8 (MCP Servers) | Top 4 MCP servers: MCP-CalculiX, MCP-Gmsh, MCP-Build123d, MCP-pyNastran | Migration §2 | 🟡 GAP: Migration has mcp_servers/ placeholder but no implementation plan or file inventory. Should list README.md at minimum. |
| Tool-Agnostic Architecture (AOM) | Abstract base classes: SolverProcessor, GeometryProcessor, MeshProcessor with specific method signatures |
Migration §2 | ✅ Migration says "Create atomizer/processors/base.py" — covered. |
| Arsenal V3 §2.3 (AOM Placement) | "All implementation mapping lands inside V2 repo paths under atomizer/contracts/, processors/, orchestrator/, optimization/, mcp_servers/" | Migration Plan V2 tree | ✅ V2 tree includes all 5 paths. Full alignment. |
| Project Standard spec §3 (Study Internals) | Study folder structure: 1_setup/, 2_iterations/, 3_results/, 3_insights/ |
Migration Plan, Arsenal V3 | 🟡 GAP: Neither Arsenal nor Migration describes study internals structure. Project Standard defines it, but no one implements engine support for 1_setup/model/ copying or 3_insights/ auto-generation. |
Defined in Migration, Not in Source
| Migration Defines | Source Coverage | Gap Type |
|---|---|---|
| Project Standard templates (~15 files) | ❌ Not in Arsenal V3. Not in AOM (yet). In separate spec doc only. | 🔴 CRITICAL: Arsenal V3 is supposed to be the canonical architecture. It's incomplete. |
atomizer/_compat.py import shim |
❌ Not in Arsenal V3 | 🟢 OK — migration-specific transition tool, not architecture |
tools/init_project.py scaffolding script |
❌ Not in Arsenal V3 | 🔴 MAJOR: If Project Standard is first-class (per Migration §5.5), Arsenal should define this. |
--project-root engine flag |
❌ Not in Arsenal V3 | 🔴 MAJOR: Needed for Project Standard study paths. Not in architecture spec. |
| Phase-by-phase rollback procedures (Migration §16) | ❌ Not in Arsenal V3 or Webster Review | 🟢 OK — operational concern, not architecture |
| Pre-commit hooks config (Migration §13) | ❌ Not in Arsenal V3 | 🟢 OK — repo hygiene, not architecture |
Summary: 5 major gaps. The biggest: Arsenal V3 doesn't define Project Standard integration, but Migration treats it as first-class architecture.
F. Naming & Path Consistency
Question: Do all documents use consistent naming for modules, folders, and components?
Folder/Module Names ✅
| Component | Arsenal V3 | Migration V3.1 | AOM (Component Map) | Consistent? |
|---|---|---|---|---|
| Contracts | atomizer/contracts/ |
atomizer/contracts/ |
atomizer/contracts/ |
✅ |
| Processors | atomizer/processors/ |
atomizer/processors/ |
atomizer/processors/ |
✅ |
| Orchestrator | atomizer/orchestrator/ |
atomizer/orchestrator/ |
atomizer/orchestrator/ |
✅ |
| Optimization | atomizer/optimization/ |
atomizer/optimization/ |
atomizer/optimization/ |
✅ |
| Extractors | atomizer/extractors/ |
atomizer/extractors/ |
atomizer/extractors/ |
✅ |
| Spec/Config | atomizer/spec/ |
atomizer/spec/ |
atomizer/spec/ |
✅ |
| Knowledge | atomizer/knowledge/ |
atomizer/knowledge/ |
atomizer/knowledge/ |
✅ |
| Dashboard | dashboard/ |
dashboard/ |
dashboard/ |
✅ |
| MCP Servers | mcp_servers/ |
mcp_servers/ |
mcp_servers/ |
✅ |
Naming is 100% consistent where all documents define the same component.
Module Renaming Consistency ✅
| V1 Name | V2 Name (Arsenal) | V2 Name (Migration) | Consistent? |
|---|---|---|---|
optimization_engine/core/runner.py |
atomizer/optimization/engine.py |
atomizer/optimization/engine.py |
✅ |
optimization_engine/extractors/extractor_library.py |
atomizer/extractors/registry.py |
atomizer/extractors/registry.py |
✅ |
optimization_engine/config/ |
atomizer/spec/ |
atomizer/spec/ |
✅ |
Component Terminology ✅
| Concept | Arsenal V3 | Migration V3.1 | AOM | Consistent? |
|---|---|---|---|---|
| Universal data types | "Contracts" | "Contracts" | "Data Contracts" | ✅ |
| Tool-specific translators | "Processors" | "Processors" | "Processors" | ✅ |
| Pipeline controller | "Orchestrator" | "Orchestrator" | "Orchestrator" | ✅ |
| Study configuration | "AtomizerSpec v3.0" | "AtomizerSpec v3.0" | "AtomizerSpec" | ✅ |
| Optimization algorithms | "Optuna/pymoo/OpenMDAO" | "Optuna/pymoo" | "Optuna/pymoo" | ✅ |
Inconsistencies 🟡
| Inconsistency | Where | Impact |
|---|---|---|
| NX placement | Arsenal: processors/geometry/nx_geometry.py. Migration: atomizer/nx/ (full module) + processors/geometry/nx_geometry.py (also listed in tree §2). |
🟡 MAJOR — both exist in V2 tree, unclear which is canonical |
| Surrogates location | Arsenal: processors/surrogates/ (9 files). Migration also has optimization/surrogates/ (GNN). Both exist. |
🟡 MINOR — Tech Lead noted this in V3 review. Need docstring clarification or consolidation. |
Verdict for Section F: 🟢 GOOD
- 99% naming consistency across all documents
- NX placement ambiguity is the only significant issue (same as structural alignment finding)
Recommendations (Prioritized)
🔴 CRITICAL (Blockers — Must Fix Before Phase 1)
| # | Recommendation | Affected Phases | Effort |
|---|---|---|---|
| C1 | Resolve contracts chicken-and-egg: Write contract stub definitions in Tool-Agnostic Architecture doc (AOM Pillar 1) NOW, before migration starts. Provide at minimum: class signatures, field lists, docstrings. OR accept contracts are post-migration and remove them from Phase 1 scope entirely. | Phase 0, Phase 1 | 🕐 4 hours (write stubs) |
| C2 | Rewrite Project Standard templates: The current template list (Migration §3.17) implements the REJECTED spec. Rewrite all 14 templates to match the APPROVED Final Recommendation: single README.md (not PROJECT+AGENT+STATUS), 4-folder KB (not 5-branch). | Phase 1 | 🕐🕐 8 hours (rewrite 14 templates) |
| C3 | Backport Project Standard to Arsenal V3: Update Arsenal V3 Final to include Project Standard as a first-class component. Add: templates/ folder, init script, --project-root flag, study path conventions. Arsenal must be the complete architecture source. | Pre-Phase 0 | 🕐🕐 6 hours (update Arsenal doc) |
🟡 MAJOR (High Priority — Resolve in Phase 0 or Phase 1)
| # | Recommendation | Affected Phases | Effort |
|---|---|---|---|
| M1 | Consolidate NX strategy: CEO decision required. Is NX (a) a processor like any other (processors/geometry/nx_geometry.py only), OR (b) a special legacy subsystem (atomizer/nx/ with all NX code including journals/). Remove one or clearly document why both exist. |
Phase 1 | 🕐 2 hours (decide + update docs) |
| M2 | Update AOM code paths: During Phase 0 AOM deployment, update 3–5 AOM docs that reference optimization_engine/ paths → atomizer/. Specifically: 02-Operations/09-NX-Integration, 03-Developer/01-Codebase-Architecture, 03-Developer/03-API-Reference. |
Phase 0 | 🕐 2 hours |
| M3 | Add Project Standard reference to AOM: Create docs/AOM/02-Operations/16-Project-Organization-Standard.md explaining the template system, init script, and --project-root integration. Cross-reference from Study Lifecycle doc. |
Phase 0 | 🕐 3 hours |
| M4 | Clarify study internals implementation: Project Standard defines 1_setup/, 2_iterations/, 3_results/, 3_insights/ study structure. Migration assumes engine supports this but doesn't specify implementation. Verify atomizer/study/creator.py creates this structure, or add to Phase 1 scope. |
Phase 1 | 🕐 4 hours (code + verify) |
| M5 | Document MCP server scope: Arsenal V3 says top 4 MCP servers (CalculiX, Gmsh, Build123d, pyNastran) are MVP. Migration has mcp_servers/ placeholder. Add mcp_servers/README.md with implementation roadmap, or explicitly defer to post-MVP. |
Phase 0 or Phase 2 | 🕐 1 hour (README) |
🟢 MINOR (Nice to Have — Address During Migration)
| # | Recommendation | Effort |
|---|---|---|
| N1 | Topology Engineer activation: Arsenal activates Topology Engineer in Sprint 3, but topology is post-MVP. Either defer activation or scope role to "benchmark prep only" as Webster suggested. | 🕐 30 min (update agent roster) |
| N2 | Surrogates consolidation: processors/surrogates/ and optimization/surrogates/ both exist. Add docstring to each __init__.py explaining the distinction (processors = classical ML, optimization = GNN). Or consolidate if redundant. |
🕐 1 hour |
| N3 | Template versioning strategy: .atomizer/template-version.json exists in template list but versioning scheme is undefined. Define format: {"standard_version": "1.0.0", "deployed_date": "2026-02-23"}. |
🕐 30 min |
Risk Assessment
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Contracts undefined causes Phase 1 failure | HIGH (if not fixed) | CRITICAL | C1: Write stubs NOW or defer contracts |
| Wrong Project Standard templates deployed | HIGH (templates are wrong) | CRITICAL | C2: Rewrite templates before Phase 1 |
| NX code fragmentation | MEDIUM | MAJOR | M1: Consolidate before Phase 1 |
| AOM paths broken after migration | MEDIUM | MAJOR | M2: Update during Phase 0 |
| Study structure assumptions break | MEDIUM | MAJOR | M4: Verify engine implementation |
| Arsenal V3 incomplete as architecture source | MEDIUM | MAJOR | C3: Backport Project Standard |
Verification Checklist (for CEO/Manager)
Before approving Phase 0 start:
- C1 resolved: Contracts either (a) have stub definitions in AOM, OR (b) are removed from Phase 1 scope
- C2 resolved: Project Standard templates rewritten to match Final Recommendation (README.md single entry, 4-folder KB)
- C3 resolved: Arsenal V3 updated to include Project Standard as first-class component
- M1 resolved: NX consolidation strategy decided and documented
- M2 tracked: AOM path updates added to Phase 0 checklist
- M3 tracked: Project Standard AOM doc added to Phase 0 deliverables
Appendices
Appendix A: Document Versions Reviewed
| Document | Version/Date | Location |
|---|---|---|
| Arsenal V3 Webster Review | 2026-02-23 | Atomizer-AtomasteAI/Development/ARSENAL-V3-WEBSTER-REVIEW.md |
| Arsenal V3 Final | 2026-02-23 | Atomizer-AtomasteAI/Development/ARSENAL-V3-FINAL.md |
| Project Standard Final Recommendation | 2026-02-19 | P-Atomizer-Project-Standard/05-FINAL-RECOMMENDATION.md |
| Migration Plan V3.1 | 2026-02-23 (V3.1 amendment) | Atomizer-AtomasteAI/Development/ATOMIZER-V2-MIGRATION-MASTERPLAN-V3.md |
| AOM MAP | 2026-02-21 | P-Atomizer-Operating-Manual/MAP - Atomizer Operating Manual.md |
| AOM Component Map | 2026-02-22 | P-Atomizer-Operating-Manual/01-Philosophy/04-Component-Map.md |
| AOM Tool-Agnostic Architecture | 2026-02-22 | P-Atomizer-Operating-Manual/01-Philosophy/08-Tool-Agnostic-Architecture.md |
Appendix B: Files Counted
- Arsenal V3: 1 architecture doc, 6 sprints, 19 agent definitions, 4 MCP servers, 3 architectural layers
- Migration Plan V3.1: 8 phases, 163 Python files, 48 AOM docs, 15+ Project Standard templates, 6 verification checklists
- Project Standard: 9 top-level items, 14 template files, 4 KB folders, 3 lifecycle phases
- AOM: 4 pillars, 48 docs (40 core + 8 auxiliary), 19 agent architecture
Appendix C: Methodology
- Read all 5 source document sets in full (Arsenal Webster Review, Arsenal Final, Project Standard Final Rec, Migration V3.1, AOM MAP + 2 key architecture docs)
- Extract structural definitions from each (folder paths, component names, module locations)
- Cross-reference systematically across 6 audit dimensions (A-F)
- Tag contradictions by severity (🔴 critical if blocks migration, 🟡 major if causes confusion, 🟢 minor if cosmetic)
- Trace gaps bidirectionally (defined in A but missing from B, AND defined in B but missing from A)
- Document every finding with section references (e.g., "Arsenal V3 §2.2 says X, Migration §3.17 says Y")
- Prioritize recommendations (Critical → Major → Minor)
TASK: Cross-document coherence audit
STATUS: complete
RESULT: 3 critical contradictions found (contracts undefined, wrong Project Standard templates, Arsenal incomplete). 5 major gaps identified. Migration can proceed after resolving C1-C3.
CONFIDENCE: high
NOTES:
- Arsenal V3 and Tool-Agnostic Architecture are directionally sound but have implementation gaps (contracts are described but not defined, Project Standard not included)
- Migration Plan V3.1 is executable AFTER correcting the Project Standard template error (currently implements rejected spec)
- The core 3-layer architecture (contracts/processors/orchestrator) is perfectly aligned across all documents — this is the strongest finding
- NX consolidation ambiguity is solvable with a CEO decision (not a documentation error, just an unstated choice)
- Recommend 1-2 day hold before Phase 0 start to resolve C1-C3
Audit completed by Auditor (Subagent) on 2026-02-23
All findings traceable to source documents with section references
Severity ratings follow Atomizer audit protocol (🔴🟡🟢)