Skip to content

Manufacturing operating system plan: completed Phases 1-3

Archived from manufacturing-operating-system-plan (the completed Phase 1, 2 and 3 sections of the implementation phases); moved verbatim, nothing summarised. Return to manufacturing-operating-system-plan.

Phase 1 — Manufacturing contract and Robot reference definition

Goal: remove ambiguity before changing production code.

Deliverables:

  1. Confirm the system map and authority table.
  2. Inventory existing repositories, ERP records, APIs, workflows, fixtures, firmware files, schemas, SOPs, and active automation. Reuse what already works.
  3. Define the identifier and naming standard.
  4. Define initial state machines for product maturity, physical board, test attempt, quarantine/rework, part lifecycle, and release promotion.
  5. Define version-one schemas for product, board, workflow, fixture, firmware manifest, BOM publication, test result, and audit event.
  6. Define roles, approval points, correction rules, retention requirements, and effective-date/serial boundaries.
  7. Map the Robot Board's current workflow and data into those definitions without changing live behavior.
  8. Produce the Robot Board compatibility manifest: hardware revision, fixture, workflow, test firmware if used, production firmware, routing, inventory mapping, and UI-contract version.
  9. Write acceptance scenarios for duplicate submission, unreadable chip, fixture failure, test failure, unlimited retest, quarantine, repair, release, scrap, server outage, and interrupted printing.
  10. Produce a gap report and Phase 2 implementation backlog, ordered by risk and dependency.

Exit criteria:

  • Every Phase 1 object has an owner and authoritative system.
  • Robot Board's existing production behavior can be represented without losing information.
  • Schemas validate representative current records.
  • State-transition scenarios have agreed expected outcomes.
  • No unresolved decision blocks the shared runner design.
  • No live database, tester, fixture, or operator procedure has changed.

Phase 2 — Repository template and validation foundation

Create the shared contract repository and update the existing product-template plan rather than creating a competing template. Add root and nested AI rules, manifests, schemas, validators, CI, build scripts, examples, CODEOWNERS, pull-request forms, and candidate artifact packaging. Prove the template through a disposable repository.

Completed 2026-09-20. Angel approved the recommended defaults: extend the existing private Project Template; pin tagged contract releases; warn for concept/prototype completeness while always blocking safety defects; leave existing product repositories unchanged; update through reviewable pull requests; use stable schema identities with bundled offline copies; use @angelEmbeddedEra as interim owner; and target Python 3.11+ with KiCad 10.

Implementation evidence:

  • Manufacturing System PR #1 merged as cd1cbe0.
  • Immutable prerelease v0.1.0-draft.1 contains the validator, schemas and composite GitHub Action.
  • Project Template PR #1 merged as 859760d.
  • The template now includes pinned manufacturing/contract.toml, nested AGENTS.md files, CODEOWNERS, manufacturing review fields, and the shared validation workflow.
  • Six focused validator tests passed. The live template passes with zero errors and four expected concept-stage warnings.
  • A disposable private repository created from the template passed the contract, manifest and full KiCad ERC/DRC workflows. It was archived after the current GitHub token lacked the delete_repo scope.
  • GitHub Actions from the private Manufacturing System repository are enabled for organization repositories.
  • GitHub branch protection is unavailable for these private repositories on the current plan; CI, pull requests and CODEOWNERS provide the controls currently available.

Phase 3 — Shared Universal Tester application

Add the common orchestrator, runner, UI contract, fixture discovery, validation, durable local queue, idempotent server submission, and board-plugin interface. Wrap the current Robot program first so behavior remains stable, then extract its steps incrementally. Keep the current launchers as temporary diagnostic fallbacks during migration.

Implementation evidence:

  • Universal Tester PR #3 merged as 3f6fdf8.
  • The opt-in shared application now provides unpowered fixture discovery, one-plugin fixture ownership, server-authoritative next-stage input, exact workflow and physical-fixture compatibility checks, a standardized operator screen contract, and safe shutdown around every attempt.
  • Every normalized attempt is written to an append-only local journal before publication. The same event ID is preserved through the existing tester-server durable outbox for idempotent replay and traceability.
  • A legacy callback adapter allows programs to migrate incrementally. Existing launchers and Robot production behavior remain unchanged; Robot activation belongs to Phase 4 bench acceptance.
  • The hardware-free integration simulation passed the complete startup-to-pass flow. Repository validation passed with 487 tests, 1 intentional skip, and 70 subtests.