docs: define PMO01 platform foundation and A to C strategy

README.md

@@ -2,6 +2,8 @@
 
 Практическая программа по Project Management уровня senior+.
 
+> **Статус:** текущая реализация — reference prototype для проверки продукта и модели обучения. Она не считается целевой архитектурой масштабируемой платформы. Актуальная стратегия и источники истины находятся в [`docs/`](docs/README.md).
+
 Это не курс по Scrum, Jira или PMBOK. Программа учит рассматривать проект как систему преобразования неопределенности в ценный результат и управлять семью потоками:
 
 1. ценность;
@@ -21,6 +23,31 @@
 - сохранение прогресса и заметок в браузере;
 - итоговый capstone длительностью 2–4 недели.
 
+## Стратегия развития
+
+Проект развивается по схеме **A → C**:
+
+1. текущий сайт сохраняется как reference prototype;
+2. на нем проверяются учебные механики и curriculum;
+3. подтвержденные требования фиксируются как продуктовые и доменные контракты;
+4. после validation gate строится отдельная масштабируемая v1;
+5. контент и механики мигрируют в v1 вертикально, только после проверки.
+
+Не следует расширять текущие `app.js` и `course-data.js` как постоянную платформенную архитектуру.
+
+## Документация
+
+Начать с [`docs/README.md`](docs/README.md).
+
+Ключевые документы:
+
+- [`docs/product/PRODUCT.md`](docs/product/PRODUCT.md) — продуктовый контракт;
+- [`docs/product/LEARNING_MODEL.md`](docs/product/LEARNING_MODEL.md) — модель обучения;
+- [`docs/product/CURRICULUM.md`](docs/product/CURRICULUM.md) — competency/curriculum contract;
+- [`docs/content/CONTENT_MODEL.md`](docs/content/CONTENT_MODEL.md) — модель контента;
+- [`docs/architecture/ARCHITECTURE.md`](docs/architecture/ARCHITECTURE.md) — текущая и целевая архитектура;
+- [`docs/ROADMAP.md`](docs/ROADMAP.md) — этапы и validation gates.
+
 ## Запуск локально
 
 Сайт не требует сборки. Откройте `index.html` или запустите любой статический HTTP-сервер из корня репозитория.

docs/README.md

@@ -0,0 +1,49 @@
+# PMO01 Documentation Map
+
+This directory is the source of truth for product, learning, content, architecture, and delivery decisions.
+
+## Current strategy
+
+PMO01 follows an **A → C** evolution path:
+
+1. Treat the current `main` implementation as a **reference prototype**.
+2. Validate which learning and product mechanisms are worth keeping.
+3. Design a separate scalable v1 architecture.
+4. Migrate only validated content, interactions, and data contracts into v1.
+
+The reference prototype is not the long-term architecture.
+
+## Documents
+
+### Product
+- `product/PRODUCT.md` — product purpose, users, value proposition, principles, non-goals.
+- `product/LEARNING_MODEL.md` — how PMO01 expects learning to happen.
+- `product/CURRICULUM.md` — competency map and curriculum contract.
+- `product/PRODUCT_REQUIREMENTS.md` — product capabilities and staged requirements.
+- `product/METRICS.md` — validation and learning-effectiveness metrics.
+
+### Content
+- `content/CONTENT_MODEL.md` — canonical entities and rules for lessons, drills, cases, assessments, and artifacts.
+
+### Architecture
+- `architecture/ARCHITECTURE.md` — current-state and target-state architecture.
+- `architecture/adr/0001-reference-prototype-to-v1.md` — decision record for the A → C strategy.
+
+### Delivery
+- `ROADMAP.md` — gates from prototype validation to scalable v1.
+
+### Design specs
+- `superpowers/specs/2026-09-03-pmo01-v0-design.md` — historical V0 design. It remains useful context but is not the current architecture source of truth.
+- `superpowers/specs/2026-09-06-pmo01-platform-foundation-design.md` — current platform foundation design.
+
+## Source-of-truth precedence
+
+When documents conflict, use this order:
+
+1. Accepted ADRs.
+2. Current platform foundation design.
+3. Product and architecture documents listed above.
+4. Historical V0 specs.
+5. Existing prototype implementation.
+
+The prototype describes what exists today. It does not override an accepted product or architecture decision for v1.

docs/ROADMAP.md

@@ -0,0 +1,169 @@
+# PMO01 Roadmap
+
+## Strategy
+
+PMO01 evolves through validation gates, not feature accumulation.
+
+```text
+Reference prototype
+→ learning validation
+→ content contract validation
+→ v1 architecture decision
+→ one-module vertical migration
+→ measured parity/improvement
+→ broader migration
+→ optional platform expansion
+```
+
+## Phase 0 — Stabilize the reference prototype
+
+Goal: make the existing product reliable enough to use as a learning experiment without turning it into the permanent architecture.
+
+Deliverables:
+
+- current product behavior documented;
+- current curriculum treated as candidate content;
+- no major new platform subsystems added;
+- obvious prototype-breaking defects fixed when they block validation;
+- a small set of representative learning paths selected for testing.
+
+Exit gate:
+
+- the prototype can support a learner through at least one complete module without critical usability/data-loss issues.
+
+## Phase 1 — Validate the learning model
+
+Goal: determine which learning mechanisms actually improve PM reasoning and transfer.
+
+Deliverables:
+
+- select one representative module;
+- audit lesson outcomes against `CURRICULUM.md`;
+- improve at least one decision drill;
+- create or validate one integrative case;
+- create one real-project field application;
+- define a rubric;
+- run learner tests using the protocol in `METRICS.md`.
+
+Exit gate:
+
+- evidence indicates the module format can reveal and improve reasoning, not merely deliver content;
+- major interaction/content failures are known;
+- the validated module can be represented by `CONTENT_MODEL.md` without ad hoc exceptions.
+
+## Phase 2 — Freeze v1 domain contracts
+
+Goal: define the minimum stable contracts that implementation may depend on.
+
+Deliverables:
+
+- final v1 content schema;
+- stable content IDs/version rules;
+- learning-state transition model;
+- assessment/rubric model;
+- learner repository interface;
+- diagnostic mapping contract;
+- migration rules from prototype content/state where relevant.
+
+Exit gate:
+
+- contracts can represent the validated module end-to-end;
+- unresolved questions are implementation details, not domain ambiguity.
+
+## Phase 3 — Select v1 technical architecture
+
+Goal: choose framework and deployment architecture based on validated requirements.
+
+Deliverables:
+
+- compare candidate approaches;
+- architecture ADR;
+- repository/file structure;
+- build/test/deploy strategy;
+- performance/accessibility constraints;
+- plan for local persistence and future remote persistence boundary.
+
+Likely candidates may include Astro or another TypeScript static-first framework, but no framework is selected by this roadmap.
+
+Exit gate:
+
+- selected architecture implements the domain contracts without coupling content to presentation;
+- migration cost is understood;
+- no deferred subsystem has been smuggled into v1 requirements.
+
+## Phase 4 — Build one-module v1 vertical slice
+
+Goal: prove the target architecture with one validated module.
+
+Deliverables:
+
+- content validation pipeline;
+- content service;
+- curriculum navigation;
+- learning runtime;
+- learner repository implementation;
+- decision drill interaction;
+- integrative case interaction;
+- field application workflow;
+- accessibility and core tests;
+- deployment.
+
+Exit gate:
+
+- the validated module works end-to-end in v1;
+- learner experience is at least as good as the prototype;
+- content can be edited without touching UI runtime code;
+- state transitions and content relationships have automated tests.
+
+## Phase 5 — Migrate validated PM curriculum
+
+Goal: move only content that passes curriculum and learning-quality audits.
+
+Process per module:
+
+1. audit outcomes and competency mapping;
+2. remove duplication;
+3. validate drills/cases/application;
+4. convert to canonical content model;
+5. migrate assets/templates;
+6. test content integrity;
+7. publish;
+8. compare learner behavior/feedback with prototype where possible.
+
+Exit gate:
+
+- all production modules satisfy curriculum/content contracts;
+- prototype is no longer required for validated PM paths.
+
+## Phase 6 — Introduce server-backed learner state only if needed
+
+Possible triggers:
+
+- cross-device progress is a validated retention need;
+- learner work must persist beyond one browser;
+- authenticated cohorts/organizations are required;
+- analytics require durable learner/event identity;
+- paid product requires account entitlement.
+
+Deliverables require a separate spec/ADR.
+
+## Phase 7 — Optional intelligence and scale features
+
+Only after core learning quality and state model are stable, evaluate separately:
+
+- AI tutor;
+- AI-assisted rubric feedback;
+- adaptive review;
+- personalized sequencing;
+- multi-program catalog;
+- team/enterprise learning;
+- authoring/CMS workflows;
+- payments/certificates.
+
+Each is an independent product decision, not a default consequence of “scaling”.
+
+## Immediate next decision
+
+Before code migration begins, review and accept the platform foundation documents in `docs/`.
+
+After acceptance, write an implementation plan for **Phase 1 only** rather than a single plan spanning the entire roadmap.