Научись управлять не задачами и статусами, а системой: потоком ценности, решений, информации, зависимостей и риска.
+
Практика управления проектами · senior+
+
Управляй системой, а не списком задач
+
Курс учит находить причину проблем проекта, принимать решения и проверять их на реальной работе. Иди по урокам по порядку — практика встроена в каждый шаг.
Каждый модуль заканчивается артефактом для реального проекта. Теория считается освоенной только после наблюдаемого изменения системы.
-
${hours[0]}–${hours[1]} ч
общая нагрузка
${progress()}%
пройдено
1
итоговое системное вмешательство
+
Основной путь
10 модулей. Иди по порядку.
Начни с первого незавершённого урока. В M01 решения и рабочая карта проверяются прямо внутри урока. Проверки и диагностика дополняют путь, но не создают второй курс.
+
${hours[0]}–${hours[1]} ч
ориентир по времени
${progress()}%
пройдено
${completedCount()}/${allLessons.length}
уроков завершено
+
Как двигаться:1. Разбери кейс2. Примени технику3. Заполни рабочий инструмент4. Проверь перенос на проект
`;
@@ -199,8 +342,8 @@
{ score: 3, label: "Системно — есть правило, владелец и обратная связь" }
];
return `
-
Baseline · 7 потоков
Диагностика зрелости
-
Оцени не намерения команды, а воспроизводимое поведение системы за последние четыре недели. Результат покажет, с какого модуля начинать.
+
Необязательная самопроверка
Где проект теряет управляемость?
+
Оцени, как проект работал последние четыре недели. Результат покажет слабое место, на которое стоит обратить внимание. Порядок курса при этом не меняется.
@@ -213,7 +356,7 @@
if (!target) return;
const answers = Object.keys(state.diagnostic);
if (answers.length < DATA.diagnostics.length) {
- target.innerHTML = `
`;
+ }
+
+ function updateLessonCompletionGate(id) {
+ const criteria = document.querySelectorAll("[data-criterion]");
+ const checked = document.querySelectorAll("[data-criterion]:checked").length;
+ const button = document.querySelector("#complete-lesson");
+ const status = document.querySelector("#completion-status");
+ const ready = checked >= criteria.length;
+ if (button) button.disabled = !ready;
+ if (status) {
+ status.textContent = `${checked}/${criteria.length} выполнено${ready ? " · можно завершать урок" : " · выполни все пункты, чтобы открыть следующий шаг"}`;
+ status.classList.toggle("ready", ready);
+ }
+ state.criteria[id] = [...document.querySelectorAll("[data-criterion]:checked")].map((item) => Number(item.dataset.criterion));
+ saveState();
+ }
+
+ function updateLabCompletionGate(id) {
+ const lesson = allLessons.find((item) => item.id === id);
+ if (!lesson?.learningLab) return;
+ const readiness = labReady(lesson);
+ const button = document.querySelector("#complete-lesson");
+ const status = document.querySelector("#completion-status");
+ if (button) button.disabled = !readiness.ready;
+ if (status) {
+ status.textContent = `${readiness.answeredDrills}/${readiness.requiredDrills} решений · ${readiness.completedFields}/${readiness.requiredFields} полей${readiness.ready ? " · можно завершать урок" : " · заверши обязательные решения и рабочую карту"}`;
+ status.classList.toggle("ready", readiness.ready);
+ }
}
function bindViewEvents(route, id) {
if (route === "lesson") {
+ const lesson = allLessons.find((item) => item.id === id);
document.querySelectorAll("[data-scroll]").forEach((link) => {
link.addEventListener("click", (event) => {
event.preventDefault();
document.querySelector(`#${link.dataset.scroll}`)?.scrollIntoView({ behavior: "smooth" });
});
});
+
document.querySelectorAll("[data-criterion]").forEach((checkbox) => {
- checkbox.addEventListener("change", () => {
- state.criteria[id] = [...document.querySelectorAll("[data-criterion]:checked")].map((item) => Number(item.dataset.criterion));
+ checkbox.addEventListener("change", () => updateLessonCompletionGate(id));
+ });
+
+ document.querySelectorAll("[data-lab-drill]").forEach((input) => {
+ input.addEventListener("change", (event) => {
+ const drillId = event.target.dataset.labDrill;
+ const lessonState = ensureLabState(id);
+ lessonState.drillAnswers[drillId] = event.target.value;
+ const drill = lesson?.learningLab?.drills.find((item) => item.id === drillId);
+ const feedback = document.querySelector(`[data-lab-feedback="${drillId}"]`);
+ if (feedback && drill) feedback.outerHTML = renderLabFeedback(drill, event.target.value);
saveState();
+ updateLabCompletionGate(id);
});
});
+
+ document.querySelectorAll("[data-lab-field]").forEach((field) => {
+ field.addEventListener("input", (event) => {
+ const lessonState = ensureLabState(id);
+ lessonState.workbook[event.target.dataset.labField] = event.target.value;
+ saveState();
+ updateLabCompletionGate(id);
+ });
+ });
+
document.querySelector("#save-notes")?.addEventListener("click", () => {
- state.notes[id] = document.querySelector("#lesson-notes").value;
+ state.notes[id] = document.querySelector("#lesson-notes")?.value || "";
saveState();
showToast("Заметки сохранены");
});
- document.querySelector("#complete-lesson")?.addEventListener("click", (event) => {
- state.notes[id] = document.querySelector("#lesson-notes").value;
- const completed = state.completed.includes(id);
- if (!completed && (state.criteria[id] || []).length < document.querySelectorAll("[data-criterion]").length) {
- saveState();
- showToast("Сначала отметь все доказательства освоения");
- return;
+
+ document.querySelector("#complete-lesson")?.addEventListener("click", () => {
+ state.notes[id] = document.querySelector("#lesson-notes")?.value || "";
+ if (lesson?.learningLab) {
+ if (!labReady(lesson).ready) {
+ updateLabCompletionGate(id);
+ showToast("Сначала заверши решения и рабочую карту");
+ return;
+ }
+ } else {
+ const criteriaCount = document.querySelectorAll("[data-criterion]").length;
+ if ((state.criteria[id] || []).length < criteriaCount) {
+ updateLessonCompletionGate(id);
+ showToast("Сначала выполни все пункты практики");
+ return;
+ }
}
- state.completed = completed ? state.completed.filter((item) => item !== id) : [...state.completed, id];
+ if (!state.completed.includes(id)) state.completed = [...state.completed, id];
saveState();
- event.currentTarget.textContent = completed ? "Отметить урок пройденным" : "Урок пройден ✓";
- event.currentTarget.classList.toggle("done", !completed);
- showToast(completed ? "Отметка снята" : "Урок добавлен в прогресс");
+ const index = allLessons.findIndex((item) => item.id === id);
+ const next = allLessons[index + 1];
+ showToast("Урок завершён");
+ location.hash = next ? `#/lesson/${next.id}` : "#/course";
});
}
@@ -300,28 +503,31 @@
const parts = location.hash.replace(/^#\/?/, "").split("/").filter(Boolean);
if (!parts.length) return { route: "home" };
if (parts[0] === "lesson") return { route: "lesson", id: parts[1] };
+ if (parts[0] === "validation" && parts[1] === "m01" && parts.length === 2) return { route: "validation-m01" };
if (["course", "diagnostic", "toolkit"].includes(parts[0])) return { route: parts[0] };
return { route: "not-found" };
}
function render() {
const { route, id } = parseRoute();
+ if (route === "validation-m01") return;
const views = { home: homeView, course: courseView, lesson: () => lessonView(id), diagnostic: diagnosticView, toolkit: toolkitView, "not-found": notFoundView };
document.querySelector("#main").innerHTML = views[route]();
setActiveNav(route);
renderSidebarProgress();
bindViewEvents(route, id);
- document.querySelector("#main").focus({ preventScroll: true });
+ document.querySelector("#main")?.focus({ preventScroll: true });
window.scrollTo(0, 0);
- document.querySelector("#mobile-nav").classList.remove("open");
- document.querySelector("#menu-button").setAttribute("aria-expanded", "false");
+ document.querySelector("#mobile-nav")?.classList.remove("open");
+ document.querySelector("#menu-button")?.setAttribute("aria-expanded", "false");
}
- document.querySelector("#menu-button").addEventListener("click", (event) => {
+ document.querySelector("#menu-button")?.addEventListener("click", (event) => {
const nav = document.querySelector("#mobile-nav");
- const open = nav.classList.toggle("open");
+ const open = nav?.classList.toggle("open") || false;
event.currentTarget.setAttribute("aria-expanded", String(open));
});
+
window.addEventListener("hashchange", render);
render();
-})();
+})();
\ No newline at end of file
diff --git a/art-direction.css b/art-direction.css
new file mode 100644
index 0000000..ad59db8
--- /dev/null
+++ b/art-direction.css
@@ -0,0 +1,409 @@
+:root {
+ --ink: #f4f2eb;
+ --ink-2: #111111;
+ --panel: #151515;
+ --paper: #f3f0e7;
+ --paper-2: #dedbd2;
+ --muted: #aaa9a2;
+ --text-secondary: #c9c8c1;
+ --text-tertiary: #aaa9a2;
+ --accent: #dfff3f;
+ --accent-2: #dfff3f;
+ --blue: #dfff3f;
+ --green: #dfff3f;
+ --red: #ff705c;
+ --line: rgba(244,242,235,.20);
+ --line-strong: rgba(244,242,235,.34);
+ --paper-line: rgba(10,10,10,.22);
+ --sidebar: 184px;
+ --radius: 0px;
+ color: var(--ink);
+ background: #0a0a0a;
+ font-family: Arial, Helvetica, sans-serif;
+}
+
+html, body { background: #0a0a0a; color: var(--ink); }
+body { overflow-x: hidden; }
+a { color: inherit; }
+
+*:focus-visible {
+ outline: 2px solid var(--accent);
+ outline-offset: 4px;
+}
+
+/* FRAME */
+.sidebar {
+ width: var(--sidebar);
+ padding: 26px 20px 22px;
+ border-right: 1px solid var(--line);
+ background: #0a0a0a;
+}
+.brand { align-items: flex-start; gap: 10px; }
+.brand-mark {
+ width: 46px;
+ height: 46px;
+ border: 1px solid var(--ink);
+ border-radius: 0;
+ background: transparent;
+ color: var(--ink);
+ font: 700 11px/1 ui-monospace, SFMono-Regular, Menlo, monospace;
+}
+.brand strong { color: var(--ink); font-size: 20px; letter-spacing: -.06em; }
+.brand small { color: var(--text-tertiary); font: 600 9px/1.35 ui-monospace, SFMono-Regular, Menlo, monospace; letter-spacing: .14em; }
+.main-nav { margin-top: 76px; gap: 0; border-top: 1px solid var(--line); }
+.main-nav a {
+ display: grid;
+ grid-template-columns: 30px 1fr;
+ gap: 8px;
+ padding: 14px 0;
+ border-bottom: 1px solid var(--line);
+ border-radius: 0;
+ background: transparent;
+ color: var(--text-secondary);
+ font-size: 13px;
+ font-weight: 650;
+}
+.main-nav a span { color: var(--text-tertiary); font: 600 10px ui-monospace, SFMono-Regular, Menlo, monospace; }
+.main-nav a:hover, .main-nav a.active { color: var(--ink); }
+.main-nav a.active { box-shadow: inset 3px 0 0 var(--accent); padding-left: 10px; }
+.main-nav a.active span { color: var(--accent); }
+.sidebar-progress { margin-top: auto; padding: 14px 0 0; border: 0; border-top: 1px solid var(--line); border-radius: 0; background: transparent; }
+.sidebar-progress .label-row { color: var(--text-tertiary); font: 10px ui-monospace, SFMono-Regular, Menlo, monospace; }
+.progress-track { height: 2px; margin-top: 10px; border-radius: 0; background: #2a2a28; }
+.progress-fill { border-radius: 0; background: var(--accent); }
+.sidebar-note { margin: 20px 0 0; color: var(--text-tertiary); font: 10px/1.55 ui-monospace, SFMono-Regular, Menlo, monospace; letter-spacing: .05em; text-transform: uppercase; }
+
+main { margin-left: var(--sidebar); background: #0a0a0a; }
+.page { max-width: 1460px; padding: 46px 54px 120px; animation: editorial-enter .32s cubic-bezier(.2,.7,.2,1); }
+@keyframes editorial-enter { from { opacity: 0; transform: translateY(10px); } }
+
+/* TYPE */
+.eyebrow {
+ margin-bottom: 14px;
+ color: var(--accent);
+ font: 700 11px/1.35 ui-monospace, SFMono-Regular, Menlo, monospace;
+ letter-spacing: .13em;
+ text-transform: uppercase;
+}
+h1, h2, h3 { color: var(--ink); font-family: Arial, Helvetica, sans-serif; }
+h1 { font-weight: 800; letter-spacing: -.08em; line-height: .88; }
+h2 { font-weight: 760; letter-spacing: -.055em; line-height: .98; }
+h3 { font-weight: 720; letter-spacing: -.03em; }
+.lead { max-width: 780px; color: var(--text-secondary); font-size: clamp(18px, 1.7vw, 23px); line-height: 1.5; }
+.mono { font-family: ui-monospace, SFMono-Regular, Menlo, monospace; }
+.muted { color: var(--text-tertiary); }
+.accent { color: var(--accent); }
+.section { margin-top: 108px; }
+.section-heading { align-items: end; padding-top: 16px; border-top: 1px solid var(--line); }
+.section-heading p { max-width: 520px; color: var(--text-secondary); line-height: 1.55; }
+
+/* HERO */
+.hero { position: relative; min-height: 72vh; padding: 18px 0 36px; display: flex; flex-direction: column; justify-content: space-between; }
+.hero::after {
+ display: block;
+ content: "PM / 0.1";
+ position: absolute;
+ top: 18px;
+ right: 0;
+ color: #4b4b47;
+ writing-mode: vertical-rl;
+ font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace;
+ letter-spacing: .2em;
+}
+.hero h1 { max-width: 1100px; margin: 0 0 24px; font-size: clamp(68px, 10.6vw, 158px); }
+.hero .lead { margin-top: auto; }
+.hero-actions { gap: 0; margin-top: 30px; }
+
+.button {
+ min-height: 46px;
+ padding: 0 17px;
+ border: 1px solid var(--line-strong);
+ border-radius: 0;
+ background: transparent;
+ color: var(--ink);
+ box-shadow: none;
+ font: 700 11px/1 ui-monospace, SFMono-Regular, Menlo, monospace;
+ letter-spacing: .04em;
+ text-transform: uppercase;
+}
+.button:hover { border-color: var(--ink); background: var(--ink); color: #0a0a0a; }
+.button.primary { border-color: var(--accent); background: var(--accent); color: #0a0a0a; }
+.button.primary:hover { border-color: var(--ink); background: var(--ink); color: #0a0a0a; }
+.button.subtle { min-height: 38px; padding: 0 12px; color: var(--ink); }
+.button.subtle:hover { border-color: var(--accent); background: transparent; color: var(--accent); }
+.button:disabled { opacity: .48; cursor: not-allowed; }
+
+/* READOUTS */
+.stat-grid { grid-template-columns: repeat(4, 1fr); gap: 0; margin-top: 66px; border-top: 1px solid var(--line); border-bottom: 1px solid var(--line); }
+.stat { min-height: 120px; padding: 18px 18px 16px 0; border-right: 1px solid var(--line); background: transparent; }
+.stat + .stat { padding-left: 18px; }
+.stat:last-child { border-right: 0; }
+.stat strong { color: var(--ink); font-size: clamp(30px, 4vw, 54px); letter-spacing: -.07em; }
+.stat span { color: var(--text-tertiary); font: 10px/1.4 ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.system-map { grid-template-columns: repeat(7, 1fr); gap: 0; border-top: 1px solid var(--line); }
+.system-node { min-height: 148px; padding: 14px 12px 16px; border: 0; border-right: 1px solid var(--line); border-radius: 0; background: transparent; box-shadow: none; }
+.system-node:last-child { border-right: 0; }
+.system-node::before { content: ""; display: block; width: 100%; height: 2px; margin-bottom: 12px; background: var(--node); }
+.system-node span { color: var(--text-tertiary); font: 600 10px ui-monospace, SFMono-Regular, Menlo, monospace; }
+.system-node strong { margin-top: 42px; color: var(--ink); font-size: 13px; line-height: 1.3; }
+
+/* NEXT ACTION */
+.next-card { grid-template-columns: 1.45fr .55fr; border: 0; border-radius: 0; background: var(--accent); color: #0a0a0a; box-shadow: none; }
+.next-card > div { padding: clamp(28px, 5vw, 64px); }
+.next-card h2 { color: #0a0a0a; font-size: clamp(42px, 6vw, 82px); }
+.next-card p { color: #20201d; }
+.next-card .eyebrow { color: #0a0a0a !important; }
+.next-card .next-meta { border-left: 1px solid rgba(10,10,10,.35); }
+.next-card .button { align-self: stretch; border-color: #0a0a0a; color: #0a0a0a; }
+.next-card .button:hover { background: #0a0a0a; color: var(--accent); }
+
+/* MODULES AS CHAPTERS */
+.module-grid { display: grid; grid-template-columns: 1fr; gap: 0; border-top: 1px solid var(--line); }
+.module-card { min-height: 220px; padding: 28px 0 34px 170px; border: 0; border-bottom: 1px solid var(--line); border-radius: 0; background: transparent; box-shadow: none; }
+.module-card::after { right: auto; left: 0; bottom: 12px; color: #292925; font-size: 118px; font-weight: 850; letter-spacing: -.1em; }
+.module-card .module-kicker { color: var(--accent); font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace; letter-spacing: .08em; }
+.module-card h3 { max-width: 720px; margin: 18px 0 10px; color: var(--ink); font-size: clamp(34px, 4vw, 60px); }
+.module-card p { max-width: 720px; color: var(--text-secondary); font-size: 16px; line-height: 1.55; }
+.module-footer { inset: auto 0 26px 170px; }
+.module-footer a { color: var(--ink); font: 700 11px ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.module-footer a:hover { color: var(--accent); }
+
+/* COURSE */
+.course-intro { grid-template-columns: minmax(0, 1.45fr) minmax(220px, .55fr); gap: 56px; align-items: end; }
+.course-intro h1 { font-size: clamp(62px, 8.6vw, 132px); }
+.course-metrics { padding: 0 0 0 18px; border: 0; border-left: 1px solid var(--line); border-radius: 0; background: transparent; box-shadow: none; }
+.course-metrics strong { color: var(--accent); font-size: 36px; }
+.course-metrics p { color: var(--text-tertiary); font: 10px ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.path-note { display: grid; grid-template-columns: 180px repeat(4, 1fr); gap: 0; margin-top: 56px; padding: 0; border-top: 1px solid var(--line); border-bottom: 1px solid var(--line); border-radius: 0; background: transparent; color: var(--ink); font-size: 12px; }
+.path-note strong, .path-note span { padding: 15px 12px; border-right: 1px solid var(--line); }
+.path-note span:last-child { border-right: 0; }
+.path-note strong { color: var(--accent); font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.path-note span { color: var(--text-secondary); }
+.module-list { gap: 0; margin-top: 34px; border-top: 1px solid var(--line); }
+.module-row { min-height: 138px; padding: 20px 0; border: 0; border-bottom: 1px solid var(--line); border-radius: 0; background: transparent; box-shadow: none; grid-template-columns: 86px minmax(240px,.9fr) 1.2fr 130px; }
+.module-row.current { box-shadow: inset 4px 0 0 var(--accent); padding-left: 16px; }
+.module-row.completed { opacity: .72; }
+.module-index { color: var(--text-tertiary); font: 650 11px ui-monospace, SFMono-Regular, Menlo, monospace; }
+.module-status { color: var(--text-tertiary); font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace; letter-spacing: .08em; text-transform: uppercase; }
+.module-row.current .module-status { color: var(--accent); }
+.module-row h2 { color: var(--ink); font-size: clamp(25px, 2.4vw, 38px); }
+.module-row p { color: var(--text-secondary); font-size: 15px; line-height: 1.5; }
+.module-row a { color: var(--ink); font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.module-row a:hover { color: var(--accent); }
+
+/* LESSON */
+.lesson-layout { grid-template-columns: minmax(0, 860px) 220px; gap: 64px; }
+.lesson-layout > article { padding: 0; border: 0; border-radius: 0; background: transparent; box-shadow: none; }
+.lesson-header { margin-bottom: 54px; padding: 10px 0 38px; border-bottom: 1px solid var(--line); }
+.lesson-header h1 { font-size: clamp(56px, 7vw, 104px); }
+.lesson-header .meta { color: var(--text-tertiary); font: 10px ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.lesson-block { margin: 60px 0; }
+.lesson-block h2 { margin-bottom: 20px; font-size: clamp(32px, 3vw, 48px); }
+.lesson-block p, .lesson-block li { color: var(--text-secondary); font-size: 18px; line-height: 1.68; }
+.insight { margin: 50px 0; padding: 24px 0 24px 24px; border-left: 3px solid var(--accent); background: transparent; color: var(--ink); font-size: clamp(24px, 2.5vw, 36px); font-weight: 700; line-height: 1.25; }
+.model-card { margin: 36px 0; padding: 24px 0; border-top: 1px solid var(--line); border-bottom: 1px solid var(--line); border-radius: 0; background: transparent; color: var(--accent); font: 13px/1.9 ui-monospace, SFMono-Regular, Menlo, monospace; }
+.practice { margin-top: 70px; padding: 34px; border: 0; border-radius: 0; background: var(--paper); color: #111; }
+.practice h2, .practice h3 { color: #111; }
+.practice .eyebrow { color: #111; }
+.practice-help, .field-help { color: #4f4f4a; font-size: 14px; }
+.criterion { padding: 13px 0; border: 0; border-bottom: 1px solid rgba(10,10,10,.18); border-radius: 0; background: transparent; }
+.criterion input { accent-color: #111; }
+.completion-status { color: #4f4f4a; font: 700 11px/1.4 ui-monospace, SFMono-Regular, Menlo, monospace; text-transform: uppercase; }
+.completion-status.ready { color: #111; }
+.notes { border: 1px solid rgba(10,10,10,.28); border-radius: 0; background: #fff; color: #111; font-size: 16px; }
+.notes:focus { outline: 2px solid #111; border-color: #111; }
+.practice .button { border-color: #111; color: #111; }
+.practice .button.primary { border-color: #111; background: #111; color: var(--paper); }
+.lesson-aside { top: 28px; }
+.lesson-aside .toc { padding: 0; border: 0; border-top: 1px solid var(--line); border-radius: 0; background: transparent; }
+.toc small { display: block; padding: 13px 0; border-bottom: 1px solid var(--line); color: var(--text-tertiary); font: 700 9px ui-monospace, SFMono-Regular, Menlo, monospace; letter-spacing: .08em; }
+.toc a { padding: 11px 0; border-bottom: 1px solid var(--line); color: var(--text-secondary); font-size: 12px; }
+.toc a:hover { color: var(--accent); }
+.lesson-nav { gap: 0; margin-top: 24px; }
+
+/* M01 LEARNING LAB */
+.learning-lab {
+ margin-top: 10px;
+ border-top: 1px solid var(--line);
+ color: var(--ink);
+}
+.learning-lab > section,
+.learning-lab > header {
+ padding: 42px 0;
+ border-bottom: 1px solid var(--line);
+}
+.lab-intro h2,
+.lab-drill h2,
+.lab-worked h2,
+.lab-technique h2,
+.lab-workbook h2,
+.lab-transfer h2 { font-size: clamp(30px, 3.4vw, 52px); }
+.lab-intro > p:last-child,
+.lab-purpose,
+.lab-situation,
+.lab-worked li,
+.lab-technique li,
+.lab-workbook > p,
+.lab-transfer p {
+ color: var(--text-secondary);
+ font-size: 17px;
+ line-height: 1.65;
+}
+.lab-step {
+ margin-bottom: 14px;
+ color: var(--accent);
+ font: 700 10px ui-monospace, SFMono-Regular, Menlo, monospace;
+ letter-spacing: .10em;
+ text-transform: uppercase;
+}
+.lab-drill fieldset { margin-top: 24px; padding: 0; border: 0; }
+.lab-drill legend { margin-bottom: 14px; color: var(--ink); font-size: 18px; font-weight: 700; line-height: 1.45; }
+.lab-options { display: grid; border-top: 1px solid var(--line); }
+.lab-option {
+ display: grid;
+ grid-template-columns: 24px 1fr;
+ gap: 12px;
+ align-items: start;
+ padding: 16px 0;
+ border-bottom: 1px solid var(--line);
+ color: var(--text-secondary);
+ font-size: 16px;
+ line-height: 1.45;
+ cursor: pointer;
+}
+.lab-option:hover { color: var(--ink); }
+.lab-option:has(input:checked) { color: var(--ink); box-shadow: inset 3px 0 0 var(--accent); padding-left: 12px; }
+.lab-option input { margin-top: 3px; accent-color: var(--accent); }
+.lab-feedback {
+ margin-top: 18px;
+ padding: 18px 20px;
+ border-left: 3px solid var(--text-tertiary);
+ background: #141414;
+ color: var(--text-secondary);
+}
+.lab-feedback strong { display: block; margin-bottom: 7px; color: var(--ink); font-size: 15px; }
+.lab-feedback p { margin: 0; color: var(--text-secondary); font-size: 16px; line-height: 1.55; }
+.lab-feedback.strong { border-left-color: var(--accent); }
+.lab-feedback.needs-work { border-left-color: var(--red); }
+.lab-worked ol,
+.lab-technique ol { padding-left: 22px; }
+.lab-worked li,
+.lab-technique li { margin: 9px 0; }
+.lab-model {
+ margin-top: 26px;
+ padding: 20px 0;
+ border-top: 1px solid var(--line);
+ border-bottom: 1px solid var(--line);
+ color: var(--accent);
+ font: 700 13px/1.7 ui-monospace, SFMono-Regular, Menlo, monospace;
+}
+.lab-workbook {
+ margin-inline: -28px;
+ padding: 42px 28px !important;
+ background: var(--paper);
+ color: #111;
+}
+.lab-workbook h2 { color: #111; }
+.lab-workbook .lab-step { color: #111; }
+.lab-workbook > p { color: #42423e; }
+.lab-fields { display: grid; gap: 0; margin-top: 28px; border-top: 1px solid rgba(10,10,10,.22); }
+.lab-field { display: grid; gap: 7px; padding: 18px 0; border-bottom: 1px solid rgba(10,10,10,.22); }
+.lab-field strong { color: #111; font-size: 16px; }
+.lab-field span { color: #4c4c47; font-size: 14px; line-height: 1.45; }
+.lab-field textarea {
+ width: 100%;
+ min-height: 88px;
+ margin-top: 5px;
+ padding: 12px;
+ border: 1px solid rgba(10,10,10,.30);
+ border-radius: 0;
+ background: #fff;
+ color: #111;
+ font: 16px/1.5 Arial, Helvetica, sans-serif;
+ resize: vertical;
+}
+.lab-field textarea:focus-visible { outline-color: #111; }
+.lab-transfer { background: transparent; }
+.lab-finish { padding-top: 34px !important; }
+.lab-finish .completion-status { color: var(--text-secondary); }
+.lab-finish .completion-status.ready { color: var(--accent); }
+.lab-finish .field-help { display: block; margin: 5px 0 10px; color: var(--text-tertiary); }
+.lab-finish .notes { background: #111; color: var(--ink); border-color: var(--line-strong); }
+.lab-finish .notes:focus-visible { outline-color: var(--accent); }
+
+/* DIAGNOSTIC / TOOLS */
+.question-card, .tool-card, .principle { border: 0; border-bottom: 1px solid var(--line); border-radius: 0; background: transparent; color: var(--ink); box-shadow: none; }
+.question-card { padding: 22px 0; }
+.question-card legend, .tool-card h3, .principle strong { color: var(--ink); }
+.option { border: 1px solid var(--line-strong); border-radius: 0; color: var(--text-secondary); background: transparent; }
+.option:has(input:checked) { border-color: var(--accent); background: rgba(223,255,63,.08); color: var(--ink); }
+.option input { accent-color: var(--accent); }
+.diagnostic-result { border: 1px solid var(--line); border-radius: 0; background: #111; color: var(--ink); box-shadow: none; }
+.result-empty, .tool-card p, .principle p { color: var(--text-secondary); }
+.tool-grid { gap: 0; border-top: 1px solid var(--line); }
+.tool-card { min-height: 260px; padding: 26px 22px 26px 0; }
+
+/* VALIDATION */
+.validation-shell { max-width: 980px; }
+.validation-hero { border-bottom-color: var(--line); }
+.validation-note { border: 1px solid var(--line); border-left: 3px solid var(--accent); border-radius: 0; background: transparent; color: var(--text-secondary); }
+.validation-step { border: 0; border-top: 1px solid var(--line); border-radius: 0; background: transparent; color: var(--ink); box-shadow: none; padding: 30px 0; }
+.validation-step > header p { color: var(--text-secondary); }
+.validation-scenario { border-radius: 0; background: #151515; color: var(--text-secondary); }
+.validation-option { border-color: var(--line-strong); border-radius: 0; color: var(--text-secondary); background: transparent; }
+.validation-option:has(input:checked) { border-color: var(--accent); background: rgba(223,255,63,.08); color: var(--ink); }
+.validation-option input { accent-color: var(--accent); }
+.validation-feedback { color: var(--text-secondary); }
+.validation-reasoning, .validation-evidence textarea { border: 1px solid var(--line-strong); border-radius: 0; background: #111; color: var(--ink); }
+.validation-state { border-color: var(--line); border-radius: 0; color: var(--text-secondary); }
+
+/* MOBILE */
+@media (max-width: 1050px) {
+ .system-map { grid-template-columns: repeat(4, 1fr); }
+ .lesson-layout { grid-template-columns: minmax(0, 760px); }
+ .lesson-aside { position: static; order: -1; }
+ .lesson-aside .toc { grid-template-columns: repeat(3, 1fr); }
+}
+
+@media (max-width: 900px) {
+ :root { --sidebar: 0px; }
+ .sidebar { display: none; }
+ main { margin-left: 0; }
+ .mobile-header { display: flex; height: 62px; padding: 0 16px; border-bottom: 1px solid var(--line); background: #0a0a0a; }
+ .mobile-header .brand-mark { width: 34px; height: 34px; }
+ .menu-button { border: 1px solid var(--line-strong); border-radius: 0; color: var(--ink); background: transparent; }
+ .mobile-nav { background: #0a0a0a; border-bottom: 1px solid var(--line); }
+ .mobile-nav a { border-bottom: 1px solid var(--line); color: var(--ink); }
+ .page { padding: 34px 18px 80px; }
+ .hero { min-height: auto; }
+ .hero h1 { font-size: clamp(58px, 17vw, 92px); }
+ .stat-grid { grid-template-columns: repeat(2,1fr); }
+ .stat:nth-child(2) { border-right: 0; }
+ .stat:nth-child(-n+2) { border-bottom: 1px solid var(--line); }
+ .system-map { grid-template-columns: repeat(2,1fr); }
+ .system-node { border-bottom: 1px solid var(--line); }
+ .next-card { grid-template-columns: 1fr; }
+ .next-card .next-meta { border-left: 0; border-top: 1px solid rgba(10,10,10,.35); }
+ .module-card { padding-left: 88px; }
+ .module-card::after { font-size: 70px; }
+ .module-footer { left: 88px; }
+ .course-intro { grid-template-columns: 1fr; }
+ .path-note { grid-template-columns: 1fr; }
+ .path-note strong, .path-note span { border-right: 0; border-bottom: 1px solid var(--line); }
+ .module-row { grid-template-columns: 48px 1fr; gap: 8px 14px; }
+ .module-row p, .module-row a { grid-column: 2; text-align: left; }
+ .lesson-layout { grid-template-columns: 1fr; }
+ .lesson-aside { position: static; }
+ .learning-lab > section, .learning-lab > header { padding: 34px 0; }
+ .lab-workbook { margin-inline: -18px; padding: 34px 18px !important; }
+}
+
+@media (max-width: 620px) {
+ .lesson-header h1 { font-size: clamp(48px, 15vw, 78px); }
+ .lab-intro > p:last-child, .lab-purpose, .lab-situation, .lab-worked li, .lab-technique li, .lab-workbook > p, .lab-transfer p { font-size: 16px; }
+}
+
+@media (prefers-reduced-motion: reduce) {
+ .page { animation: none; }
+ * { scroll-behavior: auto !important; transition: none !important; }
+}
diff --git a/content-overrides.js b/content-overrides.js
new file mode 100644
index 0000000..1e1e87d
--- /dev/null
+++ b/content-overrides.js
@@ -0,0 +1,59 @@
+(function () {
+ "use strict";
+ const DATA = window.PM01;
+ if (!DATA || !Array.isArray(DATA.modules)) return;
+
+ const module = DATA.modules.find((item) => item.id === "m01");
+ if (!module) return;
+
+ module.subtitle = "Смотреть на проект целиком";
+ module.outcome = "Разобраться, как устроен твой проект, найти главное слабое место и выбрать одно изменение с понятным эффектом.";
+
+ const first = module.lessons.find((lesson) => lesson.id === "project-system");
+ if (first) {
+ first.title = "Смотри на проект целиком";
+ first.thesis = "Проект — это не список задач. Это система, которая должна привести к полезному результату.";
+ first.body = [
+ "Срок, бюджет и список задач важны, но сами по себе не делают проект успешным. Можно всё закончить вовремя и при этом получить результат, который никому не нужен.",
+ "Поэтому сначала смотри на то, что должно измениться для пользователя или бизнеса. Затем проверь, что мешает команде стабильно прийти к этому результату.",
+ "Для этого мы используем семь потоков: ценность, работа, информация, решения, зависимости, неопределённость и обратная связь. Если один поток тормозит, проблема часто проявляется совсем в другом месте."
+ ];
+ first.model = "Что есть на входе → как работает команда → что мы узнали → какой результат получили\n\nИщи: где поток тормозит → сколько стоит задержка → что изменить";
+ first.practice = [
+ "Возьми один текущий или недавний проект.",
+ "Одним предложением опиши, что должно измениться для пользователя или бизнеса.",
+ "По каждому из семи потоков запиши один наблюдаемый факт.",
+ "Выбери один разрыв, который сильнее всего мешает проекту двигаться дальше."
+ ];
+ first.criteria = [
+ "Понятно, какой результат должен измениться во внешнем мире",
+ "Есть по одному факту для всех семи потоков",
+ "Факты отделены от предположений",
+ "Выбран один главный разрыв"
+ ];
+ }
+
+ const second = module.lessons.find((lesson) => lesson.id === "system-diagnostic");
+ if (second) {
+ second.title = "Сначала найди причину";
+ second.thesis = "Не исправляй первый заметный симптом. Сначала пойми, почему проблема вообще возникла и почему она может повториться.";
+ second.body = [
+ "Если тестировщик нашёл дефект, причина не обязательно в разработчике. Она могла появиться раньше: например, требование было двусмысленным или решение слишком долго ждали от другого человека.",
+ "Разбирай проблему по цепочке: что мы увидели → как это возникло → какое условие в системе это создало → что нужно изменить.",
+ "Хорошая причина не звучит как имя человека. Она описывает правило, ограничение, зависимость или способ работы, из-за которого проблема повторится даже с другой командой."
+ ];
+ second.model = "СИМПТОМ\n↓ что мы видим\nМЕХАНИЗМ\n↓ как это возникло\nУСЛОВИЕ СИСТЕМЫ\n↓ почему повторится\nИЗМЕНЕНИЕ\n↓ что делаем иначе";
+ second.practice = [
+ "Возьми одну повторяющуюся проблему проекта.",
+ "Опиши минимум три шага от симптома к причине.",
+ "Найди условие, из-за которого проблема повторится даже с другим человеком.",
+ "Предложи одно изменение и ранний сигнал, по которому поймёшь, что оно помогает."
+ ];
+ second.criteria = [
+ "Причина описывает систему, а не конкретного человека",
+ "Понятно, как проблема возникает снова",
+ "Предлагаемое изменение влияет именно на найденную причину",
+ "Есть ранний сигнал, по которому можно проверить эффект"
+ ];
+ }
+})();
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..0749751
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,61 @@
+# 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.
+
+### Validation
+- `validation/M01-VALIDATION-PROTOCOL.md` — operational protocol for the first end-to-end learner validation cycle.
+- `validation/M01-READINESS-AUDIT.md` — curriculum, learning-model, and content-contract audit before real learner sessions.
+- `validation/M01-SESSION-RECORD-TEMPLATE.md` — per-participant evidence and facilitator observation template.
+- `validation/M01-COHORT-REVIEW-TEMPLATE.md` — cohort synthesis and explicit Phase 1 exit decision record.
+
+### 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.
+
+## Current gate
+
+The technical/reference-prototype work required to run the first M01 validation cohort is prepared. The project remains in **Phase 1 — Validate the learning model** until real learner evidence is reviewed.
+
+Do not begin Phase 2 contract freeze solely because the prototype and CI are ready. Phase 2 requires an explicit cohort decision recorded with `validation/M01-COHORT-REVIEW-TEMPLATE.md`.
+
+## 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.
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
new file mode 100644
index 0000000..6c78040
--- /dev/null
+++ b/docs/ROADMAP.md
@@ -0,0 +1,181 @@
+# 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”.
+
+## Current gate — complete Phase 1 with real learner evidence
+
+The platform foundation and the technical M01 validation slice are prepared for review. The remaining Phase 1 gate is empirical, not architectural.
+
+Before Phase 2 begins:
+
+1. run at least 5 completed M01 learner sessions using `docs/validation/M01-VALIDATION-PROTOCOL.md`;
+2. record each session with `docs/validation/M01-SESSION-RECORD-TEMPLATE.md`;
+3. review diagnostic reasoning delta, field transfer, reflection quality, interaction usefulness, reliability/friction, and content-model fit;
+4. record one explicit cohort decision with `docs/validation/M01-COHORT-REVIEW-TEMPLATE.md`:
+ - **Promote to Phase 2**;
+ - **Revise and retest**;
+ - **Reject mechanism**.
+
+`docs/validation/M01-READINESS-AUDIT.md` documents the current curriculum/content-contract fit before learner testing.
+
+Do not freeze v1 domain contracts, select a framework, or start a v1 migration until the cohort decision is **Promote to Phase 2**.
diff --git a/docs/architecture/ARCHITECTURE.md b/docs/architecture/ARCHITECTURE.md
new file mode 100644
index 0000000..e94a1af
--- /dev/null
+++ b/docs/architecture/ARCHITECTURE.md
@@ -0,0 +1,259 @@
+# PMO01 Architecture
+
+## Architecture status
+
+PMO01 currently has two architectural descriptions:
+
+1. the working static prototype on `main`;
+2. the historical V0 Astro design spec.
+
+Neither is automatically the target v1 architecture.
+
+The accepted strategy is **A → C**:
+
+- preserve the current prototype as a product/learning reference;
+- validate useful mechanisms;
+- design a scalable v1 architecture from validated requirements;
+- migrate selectively.
+
+## Current reference prototype
+
+Current implementation characteristics:
+
+```text
+index.html
+ ↓
+app.js
+ ├── routing
+ ├── rendering
+ ├── learner state
+ ├── diagnostics
+ ├── interaction binding
+ └── toolkit behavior
+
+course-data.js
+ ├── flows
+ ├── modules
+ ├── lessons
+ ├── diagnostics
+ └── tools
+
+localStorage
+ └── learner progress / notes / diagnostic answers
+```
+
+Strengths:
+
+- extremely low operational complexity;
+- deployable as static files;
+- useful as a learning-format prototype;
+- no backend dependency;
+- fast to change during discovery.
+
+Scaling constraints:
+
+- content is embedded in JavaScript application data;
+- routing, rendering, interaction logic, and learner state are concentrated in one application file;
+- binary completion cannot represent stronger learning evidence;
+- no explicit content version model;
+- diagnostics are coupled directly to prototype data structures;
+- adding many programs or authors would increase coupling and review risk;
+- server-backed identity, sync, analytics, or AI would require new boundaries rather than incremental additions inside `app.js`.
+
+## Architectural principles for v1
+
+1. **Content is data, not application code.**
+2. **Learning domain logic is independent from page rendering.**
+3. **Learner state is behind an interface.** Local and remote persistence must be replaceable.
+4. **Content IDs and versions are stable.**
+5. **Static-first delivery remains preferred while requirements permit it.**
+6. **Interactive behavior is introduced only where learning needs it.**
+7. **AI is an optional adapter, not the source of curriculum truth.**
+8. **Framework choice follows validated product requirements.** Do not select v1 technology solely because the old V0 spec named Astro.
+
+## Target logical architecture
+
+```text
+ ┌─────────────────────┐
+ │ Content packages │
+ │ programs/modules/...│
+ └──────────┬──────────┘
+ │ validate/parse
+ ┌──────────▼──────────┐
+ │ Content service │
+ │ stable read model │
+ └──────────┬──────────┘
+ │
+ ┌────────────────────┼────────────────────┐
+ │ │ │
+┌─────────▼────────┐ ┌─────────▼────────┐ ┌────────▼─────────┐
+│ Learning runtime│ │ Curriculum nav │ │ Assessment logic │
+│ state transitions│ │ sequence/context │ │ rubrics/evidence │
+└─────────┬────────┘ └─────────┬────────┘ └────────┬─────────┘
+ └────────────────────┼────────────────────┘
+ │
+ ┌──────────▼──────────┐
+ │ Presentation layer │
+ │ pages/components/UI │
+ └──────────┬──────────┘
+ │
+ ┌──────────▼──────────┐
+ │ Learner repository │
+ │ local or remote │
+ └─────────────────────┘
+```
+
+## Core boundaries
+
+### 1. Content package
+
+Owns curriculum definitions and editorial material.
+
+Does not own:
+
+- learner progress;
+- UI components;
+- authentication;
+- analytics transport.
+
+### 2. Content service
+
+Consumes validated content definitions and exposes a stable application-facing interface.
+
+Examples of conceptual reads:
+
+```ts
+getProgram(programId)
+getModule(moduleId)
+getLesson(lessonId)
+getNextLearningUnit(currentId)
+getAssessment(assessmentId)
+```
+
+Storage format is hidden behind this boundary.
+
+### 3. Learning runtime
+
+Owns state transitions and rules such as:
+
+- studied;
+- applied;
+- mastered;
+- recent activity;
+- evidence references.
+
+It must not render HTML or know where content files live.
+
+### 4. Assessment domain
+
+Owns decision drills, case responses, rubrics, and evidence semantics.
+
+Automated scoring is optional. The model must allow human/self/AI-assisted evaluation later without redefining content IDs.
+
+### 5. Learner repository
+
+Persistence interface for progress, responses, and notes.
+
+Initial implementations may use browser storage. Future implementations may use a backend.
+
+The UI must not call `localStorage` directly.
+
+### 6. Presentation layer
+
+Owns navigation, reading experience, controls, feedback presentation, and accessibility.
+
+It consumes domain interfaces and does not define curriculum semantics.
+
+## Data flow
+
+### Lesson load
+
+```text
+route
+→ content service resolves lesson
+→ runtime loads learner state
+→ page renders lesson + state
+```
+
+### Decision drill
+
+```text
+learner selects action
+→ assessment domain records response
+→ feedback model resolves analysis
+→ learner repository persists response
+→ UI displays mechanism/trade-offs
+```
+
+### Field application
+
+```text
+application task
+→ learner creates evidence / response
+→ repository stores reference or content
+→ assessment/runtime updates applied state when criteria are met
+```
+
+## Error handling principles
+
+V1 should fail explicitly for content-integrity errors.
+
+Examples:
+
+- duplicate IDs;
+- missing referenced drill;
+- invalid module order;
+- unknown competency reference;
+- incompatible content version.
+
+These should fail build/publish validation rather than produce broken learner pages.
+
+Runtime persistence failures should preserve the learning page and surface a clear state-saving error rather than discard learner input silently.
+
+## Technology decision
+
+No final v1 framework is accepted yet.
+
+The historical Astro recommendation remains a candidate because static-first content and interactive islands fit the product well, but framework selection should be made in a dedicated architecture decision after the validation gate.
+
+Candidate evaluation criteria:
+
+- content pipeline quality;
+- static generation;
+- TypeScript support;
+- accessibility ergonomics;
+- testability;
+- deployment portability;
+- incremental interactivity;
+- migration cost from the prototype;
+- future support for authenticated/server-backed features without corrupting domain boundaries.
+
+## Migration strategy
+
+Do not rewrite the entire prototype before validation.
+
+Migration should happen vertically:
+
+1. select one validated module;
+2. express it in the canonical content model;
+3. implement content validation;
+4. implement the minimum learning runtime;
+5. reproduce its learning experience in v1;
+6. compare behavior and usability;
+7. only then migrate remaining validated modules.
+
+The reference prototype remains available for comparison until v1 reaches functional parity for validated learning paths.
+
+## Testing architecture
+
+Required test layers for v1:
+
+- content schema/relationship validation;
+- unit tests for learning-state transitions;
+- unit tests for diagnostic recommendation rules;
+- interaction tests for drills/cases;
+- navigation integration tests;
+- a small number of end-to-end learner paths;
+- accessibility checks for interactive controls.
+
+Do not build a large E2E suite before domain contracts stabilize.
diff --git a/docs/architecture/adr/0001-reference-prototype-to-v1.md b/docs/architecture/adr/0001-reference-prototype-to-v1.md
new file mode 100644
index 0000000..c470d51
--- /dev/null
+++ b/docs/architecture/adr/0001-reference-prototype-to-v1.md
@@ -0,0 +1,101 @@
+# ADR 0001 — Evolve from Reference Prototype to Scalable V1
+
+- Status: Accepted
+- Date: 2026-09-06
+
+## Context
+
+PMO01 has a working static prototype on `main` and a historical V0 design that proposed Astro, Markdown-first content, and a single FLOW vertical slice.
+
+The working prototype moved beyond that V0 scope: it contains a broader curriculum, diagnostics, local learner state, notes, and tools. At the same time, its implementation couples content, routing, rendering, learner state, and interactions too tightly for long-term multi-program growth.
+
+Three options were considered:
+
+### Option A — Keep evolving the current prototype
+
+Advantages:
+
+- low immediate cost;
+- preserves working behavior;
+- fastest path for experiments.
+
+Disadvantages:
+
+- increasing coupling;
+- difficult content/version management;
+- poor foundation for accounts, richer assessment, multiple curricula, or teams;
+- high risk of turning prototype structure into permanent architecture.
+
+### Option B — Return to the historical V0 Astro design
+
+Advantages:
+
+- simpler vertical slice;
+- clean static/content-first direction.
+
+Disadvantages:
+
+- discards useful work and product discoveries;
+- treats an older design document as more authoritative than observed prototype requirements;
+- framework choice precedes renewed validation.
+
+### Option C — Immediately rewrite as a scalable v1
+
+Advantages:
+
+- strongest theoretical separation of concerns;
+- removes prototype constraints early.
+
+Disadvantages:
+
+- high overengineering risk;
+- architecture could encode unvalidated learning interactions;
+- migration scope is large before the product has proven what must be retained.
+
+## Decision
+
+Use **A → C**.
+
+1. Preserve the current `main` implementation as a **reference prototype**.
+2. Stop treating prototype architecture as the default place for long-term expansion.
+3. Validate learning format, curriculum elements, diagnostics, and interactions with real users.
+4. Define stable product, learning, content, and data contracts.
+5. Design scalable v1 after those contracts are sufficiently validated.
+6. Migrate vertically, starting with one validated module.
+7. Retire prototype behavior only after v1 reproduces or improves the validated learning experience.
+
+## Consequences
+
+### Positive
+
+- avoids throwing away working product evidence;
+- delays irreversible architecture decisions;
+- provides a controlled migration path;
+- makes content and learning logic first-class domains;
+- enables future programs without making them current requirements.
+
+### Negative
+
+- two implementations may coexist temporarily;
+- some prototype work will not be migrated;
+- short-term feature requests may need to be rejected if they deepen prototype coupling;
+- migration requires explicit comparison and content audit.
+
+## Guardrails
+
+Until a v1 architecture spec is accepted:
+
+- do not add backend/auth/CMS/AI architecture to the prototype;
+- do not expand `course-data.js` as if it were the permanent content system;
+- do not turn `app.js` into a generalized platform runtime;
+- prototype-only experiments are allowed when cheap and reversible;
+- new prototype work should be justified by a validation question.
+
+## Revisit conditions
+
+Revisit this ADR only if:
+
+- the reference prototype proves inadequate even for validation;
+- a hard external requirement forces server-backed functionality before the validation gate;
+- the content model cannot represent a validated learning module without major special cases;
+- evidence shows a different product direction.
diff --git a/docs/content/CONTENT_MODEL.md b/docs/content/CONTENT_MODEL.md
new file mode 100644
index 0000000..d13019a
--- /dev/null
+++ b/docs/content/CONTENT_MODEL.md
@@ -0,0 +1,188 @@
+# PMO01 Content Model
+
+## Goal
+
+Separate learning content from presentation and runtime behavior so that curricula can evolve, be versioned, validated, and reused without editing application code.
+
+## Canonical entities
+
+### Program
+
+A complete curriculum package.
+
+Required fields:
+
+```yaml
+id: pm-core
+version: 1
+slug: project-management
+locale: ru
+status: draft | validated | published | retired
+```
+
+### Module
+
+A coherent competency unit inside a program.
+
+Required fields:
+
+```yaml
+id: flow-management
+program: pm-core
+order: 4
+title: Flow management
+competencies:
+ - C4
+estimated_minutes: 240
+```
+
+A module also references:
+
+- lesson IDs;
+- integrative case ID;
+- field application ID;
+- prerequisite competency IDs when necessary.
+
+### Lesson
+
+A focused learning unit with one primary outcome.
+
+Required metadata:
+
+```yaml
+id: queues
+module: flow-management
+order: 2
+title: Queues
+estimated_minutes: 40
+competencies:
+ - C4
+outcome: "Given delivery evidence, diagnose harmful queue formation and choose a first intervention."
+status: draft | validated | published | retired
+```
+
+Canonical lesson content sections:
+
+1. problem frame;
+2. principle;
+3. mental model;
+4. mechanism;
+5. failure pattern;
+6. worked example;
+7. decision drill references;
+8. application task reference;
+9. evidence criteria;
+10. reflection prompt.
+
+The storage format may use Markdown plus structured front matter. UI components must consume parsed content rather than import lesson text from application source files.
+
+### Decision Drill
+
+```yaml
+id: queues-drill-01
+competencies:
+ - C4
+scenario: ...
+choices:
+ - id: a
+ text: ...
+analysis:
+ preferred_choice: b
+ mechanism: ...
+ tradeoffs: ...
+ change_conditions: ...
+```
+
+A drill may have a preferred action, but feedback must explain context and trade-offs.
+
+### Integrative Case
+
+A multi-concept scenario used near the end of a module.
+
+Required properties:
+
+- case evidence;
+- learner diagnosis prompt;
+- intervention decision;
+- rationale prompt;
+- evidence/change-condition prompt;
+- assessment rubric.
+
+### Field Application
+
+A task performed on a real or recent project.
+
+Required properties:
+
+- context requirement;
+- action steps;
+- expected artifact;
+- evidence criteria;
+- reflection prompts;
+- privacy guidance when real work data is involved.
+
+### Artifact Template
+
+A reusable working document such as an assumption map or dependency map.
+
+Templates are content assets, not hard-coded download strings in application code.
+
+### Assessment Rubric
+
+Rubrics define how reasoning or application is evaluated.
+
+A rubric must contain observable dimensions rather than generic labels such as "good answer".
+
+Example dimensions:
+
+- mechanism identified;
+- relevant evidence used;
+- trade-offs acknowledged;
+- intervention matches diagnosis;
+- change condition stated.
+
+## Learner-state entities
+
+Content definitions must not contain learner state.
+
+Learner state belongs to the learning runtime and references immutable content IDs.
+
+Minimum conceptual state:
+
+```ts
+type LearningState =
+ | 'unseen'
+ | 'studied'
+ | 'applied'
+ | 'mastered';
+```
+
+Runtime records should be keyed by program version + content ID so future content changes do not silently corrupt historical progress.
+
+## Versioning rules
+
+1. Editorial correction with unchanged learning outcome may keep the same content version.
+2. A changed learning outcome, rubric, or assessment semantics requires a new version.
+3. Published IDs are stable and must not be reused for different concepts.
+4. Retired content remains resolvable for historical learner records.
+5. Migration between program versions must be explicit when accounts/server persistence exist.
+
+## Validation rules
+
+Before content is published, automated or editorial validation should verify:
+
+- unique IDs;
+- valid module/lesson references;
+- valid competency references;
+- deterministic ordering;
+- required fields present;
+- no broken drill/case/artifact references;
+- no published lesson without a measurable outcome.
+
+## V1 storage recommendation
+
+Use structured Markdown/YAML or an equivalent repository-native content format first.
+
+Do not introduce a CMS until authoring friction, multi-author workflows, publishing permissions, or content volume demonstrate the need.
+
+The application must depend on a content interface, not on the repository storage format directly. This keeps a future CMS migration possible without rewriting learning UI.
diff --git a/docs/product/CURRICULUM.md b/docs/product/CURRICULUM.md
new file mode 100644
index 0000000..2c0a1e7
--- /dev/null
+++ b/docs/product/CURRICULUM.md
@@ -0,0 +1,123 @@
+# PMO01 Curriculum Contract
+
+## Purpose
+
+The curriculum defines what a strong PM should be able to diagnose and do after completing PMO01. It is independent from the current number of modules or the UI used to deliver them.
+
+## Organizing model: seven project flows
+
+PMO01 uses seven flows as the primary diagnostic lens:
+
+1. **Value** — how work connects to an observable user or business outcome.
+2. **Work** — how work moves through the delivery system.
+3. **Information** — how quickly relevant facts reach the people who need them.
+4. **Decisions** — how decisions are made, owned, and delayed.
+5. **Dependencies** — what blocks downstream valuable action.
+6. **Uncertainty** — what must be true but has not yet been demonstrated.
+7. **Feedback** — how the system detects error and updates behavior.
+
+These flows are the stable conceptual backbone. Module boundaries may change during content validation.
+
+## Target competencies
+
+A learner completing the core PM curriculum should be able to:
+
+### C1. System diagnosis
+- define the project as a system producing an outcome;
+- distinguish symptom, mechanism, systemic condition, and intervention;
+- identify the flow in which a failure originates rather than only where it appears.
+
+### C2. Outcome and value reasoning
+- distinguish output from outcome;
+- express causal assumptions between work and business/user effect;
+- identify weak links in an outcome hypothesis.
+
+### C3. Dependency and criticality reasoning
+- model technical, organizational, decision, and external dependencies;
+- reason about downstream impact rather than list priority;
+- identify constraints and high-leverage nodes.
+
+### C4. Flow management
+- identify queues, work accumulation, batching, handoff loss, and bottlenecks;
+- understand why local utilization can reduce system throughput;
+- select interventions that improve flow rather than local productivity optics.
+
+### C5. Uncertainty and risk
+- make assumptions explicit;
+- prioritize uncertainty by confidence, impact, and reversibility;
+- design evidence-producing experiments before irreversible commitments.
+
+### C6. Decision architecture
+- identify decision rights and decision latency;
+- design escalation and ownership mechanisms;
+- separate reversible from difficult-to-reverse decisions.
+
+### C7. Information and feedback
+- identify missing, delayed, or distorted information;
+- design feedback loops with clear consumers and decisions;
+- distinguish status reporting from information that changes action.
+
+### C8. Intervention design
+- choose a management intervention based on mechanism rather than symptom;
+- define expected effect, risk, early signal, and stop/change condition;
+- review intervention results and update the mental model.
+
+## Curriculum progression
+
+The canonical progression is:
+
+```text
+Observe the system
+→ Model causes and flows
+→ Expose uncertainty and constraints
+→ Choose an intervention
+→ Collect evidence
+→ Update the system
+```
+
+This progression matters more than preserving any historical module numbering.
+
+## Module contract
+
+Every production module must define:
+
+- `id` and title;
+- competency targets;
+- prerequisite competencies, if truly required;
+- 2–5 lessons with distinct learning outcomes;
+- at least one decision drill;
+- one integrative/boss case;
+- one field application artifact or intervention;
+- evidence criteria;
+- expected learner effort;
+- assessment rule for any claimed mastery.
+
+## Lesson outcome contract
+
+Each lesson outcome must use observable behavior. Prefer:
+
+> "Given X project evidence, the learner can diagnose Y and choose Z with an explicit rationale."
+
+Avoid outcomes such as:
+
+- understand queues;
+- learn dependencies;
+- know risk management.
+
+## Current prototype mapping
+
+The existing prototype contains 10 modules and 20 lessons organized around the seven flows and adjacent system-management concepts. That content is treated as **candidate curriculum**, not automatically canonical curriculum.
+
+Before migration to v1, each lesson must be audited against:
+
+1. a target competency;
+2. a unique learning outcome;
+3. a valid decision/application activity;
+4. evidence criteria;
+5. redundancy with neighboring lessons.
+
+Lessons that fail this audit should be merged, rewritten, or removed rather than migrated unchanged.
+
+## Future curricula
+
+The platform architecture should permit other professional curricula, but PMO01 core content remains a separately versioned curriculum package. Future programs must define their own competency maps rather than reuse the seven PM flows by default.
diff --git a/docs/product/LEARNING_MODEL.md b/docs/product/LEARNING_MODEL.md
new file mode 100644
index 0000000..b756c74
--- /dev/null
+++ b/docs/product/LEARNING_MODEL.md
@@ -0,0 +1,143 @@
+# PMO01 Learning Model
+
+## Learning objective
+
+PMO01 is designed to change how a learner diagnoses and manages projects, not only what they can recall.
+
+The core instructional loop is:
+
+```text
+Concept
+ ↓
+Case
+ ↓
+Decision
+ ↓
+Feedback
+ ↓
+Reflection
+ ↓
+Transfer to a real project
+ ↓
+Evidence
+ ↓
+Updated mental model
+```
+
+## What counts as learning
+
+A learner has not mastered a concept because they opened a page or selected the expected answer.
+
+Evidence of learning should progress through four levels:
+
+1. **Recognize** — identify the concept in a described situation.
+2. **Reason** — explain mechanism, consequences, and trade-offs.
+3. **Apply** — use the concept in an unfamiliar case.
+4. **Transfer** — apply it to a real project and produce evidence from the intervention.
+
+The platform may track completion before it can reliably track mastery, but it must not label page visits as mastery.
+
+## Canonical lesson sequence
+
+A lesson should normally contain:
+
+1. **Problem frame** — why the concept matters.
+2. **Principle** — the central claim.
+3. **Mental model** — a reusable representation.
+4. **Mechanism** — why the system behaves this way.
+5. **Failure pattern** — a plausible but weak management response.
+6. **Worked example** — the model applied to a concrete situation.
+7. **Decision drill** — a realistic choice with consequences and trade-offs.
+8. **Application task** — work on the learner's own project.
+9. **Evidence criteria** — observable conditions for claiming the task was completed.
+10. **Reflection prompt** — what changed in the learner's model or next decision.
+
+Not every lesson needs separate UI blocks for all ten stages. The sequence is an instructional contract, not a layout requirement.
+
+## Decision drills
+
+Decision drills are not trivia questions.
+
+A valid drill:
+
+- describes a realistic project situation;
+- provides multiple plausible actions;
+- forces prioritization or trade-offs;
+- reveals analysis after the learner chooses;
+- explains downstream consequences;
+- can have a preferred action without pretending all ambiguity disappears.
+
+A weak drill asks for a definition or rewards superficial recall.
+
+## Boss cases / integrative cases
+
+Each module should end with an integrative case that combines multiple concepts from the module.
+
+A boss case should require the learner to:
+
+1. diagnose the system;
+2. identify missing or misleading evidence;
+3. choose an intervention;
+4. explain why competing interventions are weaker or premature;
+5. state what evidence would cause them to change course.
+
+## Field practice
+
+Every module should produce at least one reusable artifact or intervention on a real or recent project.
+
+Examples:
+
+- system map;
+- assumption map;
+- dependency graph;
+- decision-latency map;
+- experiment design;
+- feedback-loop design;
+- operating rule;
+- intervention review.
+
+The artifact exists to improve a decision, not to satisfy a template requirement.
+
+## Feedback model
+
+Feedback should explain:
+
+- what mechanism the learner noticed or missed;
+- what trade-off their action creates;
+- what evidence matters next;
+- what alternative action becomes appropriate under different conditions.
+
+Avoid celebratory correctness UI as the primary signal of learning.
+
+## Mastery model
+
+V1 should separate these states:
+
+- `unseen` — not engaged with;
+- `studied` — lesson completed;
+- `applied` — application task submitted or explicitly evidenced;
+- `mastered` — demonstrated reasoning/application under a defined assessment rule.
+
+The exact mastery algorithm is intentionally deferred until PMO01 has enough evidence to define it without fake precision.
+
+## Spacing and retrieval
+
+For scalable v1, the content model must permit later addition of spaced review and retrieval practice. These are optional future capabilities, not requirements for the reference prototype.
+
+If added, review should target mental models and decisions, not rote terminology.
+
+## Personalization
+
+Personalization should eventually adapt sequence, examples, and review based on demonstrated gaps. It must not replace the curriculum's competency model with opaque AI recommendations.
+
+The diagnostic can recommend a starting point, but diagnostic scores are hypotheses about learning needs, not proof of competence.
+
+## Learning-quality gate
+
+Before a learning interaction is promoted into scalable v1, it should pass three questions:
+
+1. Does it expose a meaningful reasoning difference between stronger and weaker PM judgment?
+2. Does the feedback explain mechanism and trade-offs rather than only the expected answer?
+3. Can the learner transfer the idea to a different case or real project?
+
+If not, the interaction should be revised or removed.
diff --git a/docs/product/METRICS.md b/docs/product/METRICS.md
new file mode 100644
index 0000000..2271d1b
--- /dev/null
+++ b/docs/product/METRICS.md
@@ -0,0 +1,168 @@
+# PMO01 Metrics and Validation
+
+## Principle
+
+PMO01 should optimize for improvement in project-management judgment, not lesson completion alone.
+
+Metrics are split into:
+
+1. learning-quality metrics;
+2. behavior/engagement metrics;
+3. product-quality metrics;
+4. migration gates.
+
+## North-star learning question
+
+> After using PMO01, can a learner diagnose a project situation and choose a stronger intervention with better reasoning than before?
+
+No single percentage can prove this. Validation should combine structured assessment and qualitative evidence.
+
+## Learning-quality metrics
+
+### L1. Diagnostic reasoning delta
+
+Measure performance on structurally similar but non-identical cases before and after a module.
+
+Score dimensions:
+
+- mechanism identified;
+- relevant evidence selected;
+- trade-offs acknowledged;
+- intervention matches diagnosis;
+- change condition stated.
+
+Use a stable rubric. Do not reuse identical questions for pre/post measurement.
+
+### L2. Transfer rate
+
+Definition:
+
+```text
+learners who complete a real-project application with evidence
+--------------------------------------------------------------
+learners who study the corresponding module
+```
+
+This is more important than page completion.
+
+### L3. Reflection quality
+
+Sample learner reflections and classify whether they show:
+
+- changed diagnosis;
+- changed planned action;
+- new evidence requirement;
+- unchanged/restated lesson content only.
+
+This can be reviewed manually during prototype validation.
+
+### L4. Delayed retrieval / application
+
+Where feasible, check whether the learner can apply the concept to a new case after a delay rather than immediately after reading.
+
+This becomes more important before any mastery label is introduced.
+
+## Engagement metrics
+
+These diagnose friction; they are not proof of learning.
+
+Track when infrastructure exists:
+
+- module start rate;
+- lesson completion rate;
+- decision-drill participation;
+- field-application start/completion;
+- return rate after first session;
+- time to first meaningful application;
+- abandonment point by learning unit.
+
+Avoid optimizing for total minutes spent.
+
+## Product-quality metrics
+
+### P1. Content integrity
+
+- zero broken references in published content;
+- zero duplicate published IDs;
+- 100% of published lessons mapped to measurable outcomes and competencies.
+
+### P2. Reliability
+
+For persisted learner work:
+
+- no silent loss of notes/responses;
+- recoverable state after ordinary page reload/navigation;
+- explicit error when persistence fails.
+
+### P3. Accessibility
+
+Critical learner paths must be keyboard operable and semantically readable.
+
+### P4. Performance
+
+Define numerical budgets when the v1 framework/deployment model is selected. Until then, the constraint is static-first rendering with minimal client JavaScript.
+
+## Prototype validation protocol
+
+Before broad v1 implementation, validate at least one complete module with real learners.
+
+Recommended minimum study:
+
+1. baseline case;
+2. module learning experience;
+3. boss/integrative case;
+4. real-project application;
+5. short interview about reasoning and friction;
+6. delayed follow-up case when practical.
+
+The goal is to discover learning and product failure modes, not to establish statistically generalizable effect size at prototype scale.
+
+## Promotion gate: interaction
+
+A learning interaction can be promoted into v1 when it demonstrates at least one of:
+
+- reveals a meaningful reasoning difference;
+- changes the learner's diagnosis;
+- improves transfer to a real project;
+- exposes a misconception worth addressing.
+
+Interactions that only create engagement or cosmetic progress should not become architectural requirements.
+
+## Promotion gate: module
+
+A prototype module is ready for migration when:
+
+- learning outcomes are explicit;
+- every lesson maps to competencies;
+- at least one decision drill has useful feedback;
+- the integrative case exercises multiple concepts;
+- field transfer is possible;
+- rubric/evidence criteria are usable;
+- major learner friction is known;
+- no unresolved content-model special case is required to represent it.
+
+## V1 success gate
+
+Do not claim scalable v1 is successful because migration is technically complete.
+
+V1 must preserve or improve:
+
+- reading usability;
+- reasoning quality;
+- transfer completion;
+- learner-state reliability;
+
+while making content maintenance and future program growth materially easier.
+
+## Metrics anti-patterns
+
+Do not use these as primary success measures:
+
+- number of pages;
+- number of lessons;
+- raw time on site;
+- XP earned;
+- streak length;
+- percentage of content opened.
+
+They may describe use but not the product's learning promise.
diff --git a/docs/product/PRODUCT.md b/docs/product/PRODUCT.md
new file mode 100644
index 0000000..6975520
--- /dev/null
+++ b/docs/product/PRODUCT.md
@@ -0,0 +1,78 @@
+# PMO01 Product Contract
+
+## Product purpose
+
+PMO01 is a learning platform for developing senior-level Project Management judgment through diagnosis, decisions, field application, and reflection.
+
+It is not primarily a reference library, certification-prep course, or tool tutorial.
+
+## Core promise
+
+Help a learner move from managing tasks and ceremonies to diagnosing projects as systems and making higher-quality management decisions under uncertainty.
+
+## Primary learner
+
+PMO01 initially targets working or recently working project/process/delivery managers who already understand basic PM vocabulary and want to improve decision quality, systems thinking, and practical execution.
+
+V1 must not require that the learner works in a specific framework such as Scrum, Kanban, SAFe, or PMBOK.
+
+## Job to be done
+
+When a project becomes delayed, uncertain, overloaded, politically difficult, or hard to diagnose, the learner should be able to:
+
+1. identify the system mechanism producing the visible symptom;
+2. distinguish output from outcome;
+3. surface assumptions and uncertainty;
+4. reason about dependencies, queues, constraints, decision latency, and feedback;
+5. choose an intervention with explicit trade-offs;
+6. collect evidence from the real project;
+7. update the diagnosis after observing the result.
+
+## Product principles
+
+1. **Decision quality over content consumption.** Reading does not equal mastery.
+2. **Real-project transfer over trivia.** Exercises should connect to work the learner actually manages.
+3. **Systems thinking over ceremony memorization.** Frameworks are tools, not the organizing model.
+4. **Evidence over confidence.** Completion and mastery must be tied to observable evidence where possible.
+5. **Reflection over correctness theater.** Plausible trade-offs are more useful than simplistic green/red answers.
+6. **Content and learning engine are separate.** The platform must support future curricula without rewriting the application.
+7. **Quiet interface.** Editorial readability and reasoning take precedence over decorative gamification.
+8. **Progressive architecture.** Do not introduce backend, AI, accounts, or generalized engines before a validated need exists.
+
+## Product boundaries
+
+### In scope for the PM curriculum
+- systems diagnosis;
+- value and outcomes;
+- dependencies and flow;
+- uncertainty and risk;
+- decision architecture;
+- information and feedback;
+- operating mechanisms;
+- interventions and learning loops.
+
+### Not the primary focus
+- Jira usage;
+- Scrum role memorization;
+- PMBOK terminology drills;
+- generic productivity advice;
+- motivational content;
+- certification exam preparation.
+
+## Platform ambition
+
+PMO01 should eventually support multiple professional learning programs while keeping the first PM curriculum coherent and deep.
+
+Possible future curricula may include Product Management, Team Leadership, Process Management, and AI-enabled management, but none are v1 requirements.
+
+## Current product state
+
+The current `main` branch is a reference prototype containing a static browser application, 10 modules / 20 lessons, seven-flow diagnostics, local progress and notes, and a toolkit.
+
+This prototype is used to validate product and learning assumptions. It is not the target architecture.
+
+## Definition of product success
+
+PMO01 succeeds if learners can demonstrate better project diagnosis and intervention reasoning after using the platform, not merely finish lessons.
+
+The validation model is defined in `METRICS.md`.
diff --git a/docs/product/PRODUCT_REQUIREMENTS.md b/docs/product/PRODUCT_REQUIREMENTS.md
new file mode 100644
index 0000000..9367d92
--- /dev/null
+++ b/docs/product/PRODUCT_REQUIREMENTS.md
@@ -0,0 +1,166 @@
+# PMO01 Product Requirements
+
+## Scope model
+
+PMO01 evolves through explicit validation gates. Requirements are separated into:
+
+- **Reference prototype requirements** — what the current implementation is allowed to prove.
+- **V1 core requirements** — what the first scalable architecture must support.
+- **Deferred capabilities** — features that require evidence before implementation.
+
+## Reference prototype
+
+The prototype exists to validate learning format and curriculum assumptions.
+
+Required behavior:
+
+- present PM learning content in a readable editorial interface;
+- support navigation across the current curriculum;
+- store lightweight progress locally;
+- store learner notes locally;
+- provide a diagnostic starting point;
+- expose reusable field-work templates;
+- support real-project application tasks;
+- remain deployable as a static site.
+
+The current implementation already demonstrates most of this behavior.
+
+## V1 core capabilities
+
+### P1. Structured content ingestion
+
+The application must load program/module/lesson/case/drill/artifact definitions through a validated content interface.
+
+Acceptance conditions:
+
+- UI code contains no lesson body text;
+- invalid content references fail validation before publication;
+- one content package can be replaced by another without changing core learning UI.
+
+### P2. Curriculum navigation
+
+The learner can:
+
+- browse programs, modules, and lessons;
+- continue from recent work;
+- understand what a module develops;
+- see prerequisite guidance when it materially affects learning.
+
+### P3. Learning interactions
+
+The runtime supports at minimum:
+
+- decision drills;
+- integrative cases;
+- field application prompts;
+- reflection prompts;
+- rubric-based assessment data structures.
+
+Not every assessment must be automatically scored.
+
+### P4. Progress model
+
+The product must distinguish engagement from learning evidence.
+
+Minimum states:
+
+- unseen;
+- studied;
+- applied;
+- mastered.
+
+V1 may initially support only part of the transition logic, but the data model must not collapse these states into a single completion boolean.
+
+### P5. Learner work
+
+The learner can persist:
+
+- notes;
+- drill/case decisions where useful;
+- field application artifacts or structured responses;
+- progress state.
+
+The first scalable release may still store data locally if validation does not yet require accounts. Storage implementation must be isolated behind an interface.
+
+### P6. Diagnostics
+
+Diagnostics may recommend where to start or what to revisit.
+
+Requirements:
+
+- recommendation logic is inspectable and deterministic unless explicitly redesigned;
+- diagnostic result is described as guidance, not proof of mastery;
+- diagnostic questions map to competencies or flows.
+
+### P7. Accessibility and readability
+
+The learning experience must support:
+
+- keyboard navigation for interactive controls;
+- readable narrow and wide layouts;
+- semantic document structure;
+- visible focus states;
+- sufficient text contrast;
+- no essential information conveyed by color alone.
+
+### P8. Content version awareness
+
+Learner state must reference stable content IDs and program/content versions so future curriculum changes do not silently rewrite historical meaning.
+
+### P9. Observability
+
+Before large-scale growth work, the product must be able to observe the minimum learning funnel defined in `METRICS.md`.
+
+Instrumentation can be added only when there is a deployment model that can collect data ethically and legally.
+
+## Deferred capabilities
+
+Do not implement these without a separate decision/spec:
+
+- accounts and authentication;
+- cloud sync;
+- team/organization dashboards;
+- payments;
+- CMS;
+- AI tutor;
+- AI assessment;
+- social features;
+- leaderboards;
+- XP/currency systems;
+- generalized knowledge graph;
+- adaptive sequencing engine;
+- native mobile applications;
+- certificates;
+- enterprise reporting.
+
+## Quality attributes
+
+### Maintainability
+- content is separated from runtime;
+- domain modules have explicit interfaces;
+- no single application file owns routing, rendering, learner state, and learning logic at scale.
+
+### Portability
+- core content and learning model should not depend on GitHub Pages;
+- hosting can change without rewriting curricula.
+
+### Testability
+- content validation is automated;
+- learning-state transitions are unit-testable;
+- drill/case behavior is testable independently from full-page rendering;
+- critical navigation paths have integration coverage.
+
+### Performance
+- static content should render with minimal client JavaScript;
+- interactive code should load only where required where practical;
+- performance budgets should be defined when the v1 framework is selected.
+
+## Release gate for scalable v1
+
+Do not start broad feature expansion until:
+
+1. the prototype learning format has been tested with real learners;
+2. at least one module has validated drills, integrative assessment, and field transfer;
+3. the canonical content model is stable enough to represent that module without special cases;
+4. migration requirements are known;
+5. the target architecture has an accepted ADR/spec.
diff --git a/docs/superpowers/plans/2026-09-06-m01-learning-validation.md b/docs/superpowers/plans/2026-09-06-m01-learning-validation.md
new file mode 100644
index 0000000..2278773
--- /dev/null
+++ b/docs/superpowers/plans/2026-09-06-m01-learning-validation.md
@@ -0,0 +1,164 @@
+# M01 Learning Validation Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Turn M01 `Проект как система` into the first measurable end-to-end learning-validation slice: baseline case → lessons/drills → integrative post-case → field application → reflection/evidence.
+
+**Architecture:** Keep the existing static prototype and leave legacy `app.js`, `course-data.js`, and `styles.css` unchanged. Add isolated M01 extension files: a pure learning-domain module, structured validation content, a post-router UI extension, and validation-specific CSS. Persist validation work under a separate `pm01-validation-m01-v1` localStorage key so the legacy app cannot erase experiment state when it writes `pm01-state-v1`.
+
+**Tech Stack:** Static HTML/CSS/JavaScript, browser `localStorage`, Node.js built-in test runner in GitHub Actions.
+
+**Spec:** `docs/superpowers/specs/2026-09-06-pmo01-platform-foundation-design.md`
+
+## Global Constraints
+
+- Current application remains a reference prototype, not the target v1 architecture.
+- Do not add backend, authentication, CMS, AI tutor/assessment, payments, or cloud sync.
+- Do not assign `mastered` automatically from page visits or a single immediate assessment.
+- Baseline and post-case must be structurally similar but non-identical.
+- Promotion signal: post-case score improves by at least 3 points and at least 2 rubric dimensions improve.
+- Learner work must survive ordinary reload/navigation via localStorage.
+- New domain logic must be testable outside the DOM.
+- M01 validation data must not share a storage key with the legacy in-memory course state.
+- Baseline score and option-level explanatory feedback must remain blind until post-case submission so the assessment itself does not become an unplanned teaching intervention.
+
+---
+
+### Task 1: Add CI and failing learning-domain tests
+
+**Files:**
+- Create: `.github/workflows/ci.yml`
+- Create: `tests/learning-domain.test.js`
+
+**Interfaces:**
+- Consumes: CommonJS exports from `learning-domain.js`.
+- Produces: executable contract for `scoreAssessment`, `promotionDecision`, and `deriveLearningState`.
+
+- [x] Add GitHub Actions CI running `node --test tests/*.test.js` on pushes and pull requests.
+- [x] Add tests for rubric totals, unanswered questions, promotion delta + dimension gate, and non-automatic mastery.
+- [x] Verify RED in Actions: tests fail specifically because `learning-domain.js` does not exist.
+
+### Task 2: Implement the pure learning domain
+
+**Files:**
+- Create: `learning-domain.js`
+
+**Interfaces:**
+- Produces: `scoreAssessment(questions, answers) -> { total, byDimension, max, answered }`.
+- Produces: `promotionDecision(baseline, post, options?) -> { promoted, delta, improvedDimensions }`.
+- Produces: `deriveLearningState({ studied, fieldApplied, transferEvidence }) -> 'unseen'|'studied'|'applied'|'mastered'`.
+
+- [x] Implement browser + CommonJS compatible module with no DOM/storage dependencies.
+- [x] Validate option scores as integers `0..3`; unanswered questions receive no invented credit.
+- [x] Implement default promotion gate: `delta >= 3` and at least two improved dimensions.
+- [x] Require explicit transfer evidence for the domain function to return `mastered`; immediate application yields at most `applied`.
+- [x] Verify GREEN in Actions.
+
+### Task 3: Add structured M01 validation content and content tests
+
+**Files:**
+- Create: `m01-validation-data.js`
+- Create: `tests/m01-content.test.js`
+
+**Interfaces:**
+- Produces: `window.PM01.m01Validation` with `rubricDimensions`, `baseline`, `decisionDrills`, `postCase`, `fieldApplication`, `reflection`.
+
+- [x] Add failing VM-based content-contract test before production content.
+- [x] Add five stable rubric dimensions: mechanism, evidence, tradeoffs, intervention, changeCondition.
+- [x] Add a five-question baseline with inspectable `0..3` options and feedback.
+- [x] Add two Decision Drills mapped to `project-system` and `system-diagnostic`.
+- [x] Add a non-identical five-question integrative post-case using the same dimensions.
+- [x] Add real-project field application requiring project, symptom, mechanism, intervention, signal, evidence, and next decision.
+- [x] Add reflection prompts comparing baseline reasoning with later reasoning.
+- [x] Verify RED before content and GREEN after content in Actions.
+
+### Task 4: Integrate the validation route and isolated learner state
+
+**Files:**
+- Modify: `index.html`
+- Create: `m01-validation-app.js`
+- Create: `tests/static-contract.test.js`
+- Create: `tests/m01-app-smoke.test.js`
+
+**Interfaces:**
+- `index.html` loads `course-data.js → m01-validation-data.js → learning-domain.js → app.js → m01-validation-app.js`.
+- Validation state persists under `pm01-validation-m01-v1`.
+- Existing course state remains under `pm01-state-v1` and is read only to determine whether both M01 lessons are completed.
+- Route: `#/validation/m01`.
+
+- [x] Add failing static-contract tests for script order, route ownership, course CTA, isolated storage, semantic controls, and validation CSS.
+- [x] Keep validation persistence separate from legacy storage after identifying stale-state overwrite risk.
+- [x] Add staged route: baseline → lesson links/drills → post-case → field application → reflection/result.
+- [x] Freeze submitted baseline/post answers and first drill choices at submission.
+- [x] Keep baseline score and option-level feedback blind after baseline submission; reveal comparison/results only after post-case submission.
+- [x] Show post score, baseline/post comparison, dimension deltas, and promotion signal only after post-case submission.
+- [x] Add a VM runtime smoke test for route rendering, post-case gates, course CTA injection, and baseline blinding.
+- [x] Verify the baseline-blinding regression test fails before the fix and passes after the fix.
+- [x] Use `promotionDecision` for a neutral learning signal, explicitly not mastery.
+- [x] Use `deriveLearningState` only up to `applied` in the UI; delayed transfer evidence remains human-review evidence.
+- [x] Add M01 validation CTA to the course view without modifying the legacy router implementation.
+- [x] Verify RED before UI extension and GREEN after integration.
+
+### Task 5: Add validation-specific styling and accessibility contracts
+
+**Files:**
+- Create: `m01-validation.css`
+- Modify: `tests/static-contract.test.js`
+
+**Interfaces:**
+- Reuses existing typography/button tokens while keeping validation selectors isolated.
+
+- [x] Add validation step, score, drill, evidence, result, and CTA styles.
+- [x] Use native radio/fieldset/legend/textarea/button controls.
+- [x] Provide explicit labels for textareas and a polite live region for persistence/validation messages.
+- [x] Convey score/state meaning with text rather than color alone.
+- [x] Add narrow-screen layout for score/drill grids.
+- [x] Verify static contracts pass.
+
+### Task 6: Document the experiment and prepare review
+
+**Files:**
+- Create: `docs/validation/M01-VALIDATION-PROTOCOL.md`
+- Modify: `README.md`
+- Modify: `.github/workflows/ci.yml`
+
+**Interfaces:**
+- Produces a reproducible learner-session protocol and makes runtime/test boundaries visible to future contributors.
+
+- [x] Document participant profile, baseline/post sequence, observations, interview prompts, field transfer, delayed follow-up, and anonymized session record.
+- [x] Define module-level review across learning signal, transfer, interaction usefulness, friction/reliability, and content-model fit.
+- [x] Document the baseline measurement-blinding rule and its rationale.
+- [x] Document M01 route, file boundaries, storage keys, and validation protocol in README.
+- [x] Add `node --check` for legacy and validation runtime JavaScript to CI.
+- [x] Upgrade GitHub Actions runtime dependencies to current major versions used by the workflow.
+- [x] Inspect final Actions run after documentation/CI changes and require GREEN.
+- [x] Review final diff for scope creep and architecture violations: Phase 1 only; no backend/auth/framework migration; legacy `app.js`, `course-data.js`, and `styles.css` unchanged.
+- [x] Update PR #2 from draft after verification; PR #2 is ready-for-review and mergeable.
+
+## Gate verification record — 2026-09-06
+
+### VERIFIED
+
+- PR #2 head is `050ea6d26197ba68f8e82d8dc34306f4c6678332`; it remains open and is not merged into `main`.
+- Stacked documentation head before this reconciliation was `82c4418de634ed2b824de5714bab34dec4e74ae9`.
+- GitHub Actions run #49 on that head completed successfully.
+- CI executed JavaScript syntax checks and `node --test tests/*.test.js`; all 19 tests passed, 0 failed, 0 skipped.
+- Full scope review of PR #2 confirms Phase 1-only changes: validation runtime/data/styles/tests/CI/docs; no backend, auth, CMS, AI subsystem, framework migration, or v1 rewrite.
+- Full scope review of the stacked docs layer confirms documentation/readiness-only changes; no runtime/application files changed.
+
+### UNEXECUTED
+
+- No merge of PR #2 into `main`.
+- No Phase 2 domain-contract freeze.
+- No framework selection or v1 migration.
+- No real learner cohort execution in this code gate.
+
+### BLOCKED
+
+- Phase 2 remains blocked on the empirical learner-evidence gate in Issue #4: at least 5 completed M01 learner sessions and one explicit cohort decision (`Promote`, `Revise and retest`, or `Reject mechanism`).
+
+### Next step
+
+1. Require GREEN CI on the new plan-reconciliation HEAD created by this update.
+2. If GREEN, treat the technical/scope gate as closed.
+3. Execute Issue #4 learner cohort before any Phase 2 work.
diff --git a/docs/superpowers/plans/2026-09-07-m01-learning-lab.md b/docs/superpowers/plans/2026-09-07-m01-learning-lab.md
new file mode 100644
index 0000000..2086dc3
--- /dev/null
+++ b/docs/superpowers/plans/2026-09-07-m01-learning-lab.md
@@ -0,0 +1,100 @@
+# M01 Learning Lab Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Turn M01 into a decision-training lab with immediate feedback, an in-lesson workbook, substantive completion gates, and readable Editorial Instrument styling.
+
+**Architecture:** Keep `app.js` as the sole owner of normal lesson routes. Add optional `learningLab` metadata to only M01 lessons from a dedicated data file. Extend generic lesson rendering/binding so M01 gets drills/workbook while M02-M10 retain existing behavior.
+
+**Tech Stack:** Static HTML/CSS/JavaScript, browser localStorage, Node `node:test` CI.
+
+**Spec:** `docs/superpowers/specs/2026-09-07-m01-learning-lab-design.md`
+
+## Global Constraints
+- Do not change `main`.
+- Do not add telemetry.
+- Do not add a new learner-facing route or router owner.
+- Preserve `pm01-state-v1` backward compatibility.
+- M02-M10 completion behavior must remain unchanged.
+- Target WCAG AA 4.5:1 for normal learner-facing text.
+
+---
+
+### Task 1: Define lab data contract and load order
+
+**Files:**
+- Create: `m01-learning-lab-data.js`
+- Modify: `index.html`
+- Test: `tests/static-contract.test.js`
+
+**Interfaces:**
+- Consumes: `window.PM01`, `window.PM01.m01Validation.decisionDrills`.
+- Produces: `lesson.learningLab = { technique, workedExample, drills, workbookFields, transferPrompt }` for the two M01 lessons.
+
+- [ ] Add a failing static-contract test requiring `m01-learning-lab-data.js` after `m01-validation-data.js` and before `app.js`, and requiring both M01 lesson IDs in the lab data file.
+- [ ] Run `node --test tests/*.test.js`; verify the new contract fails because the file/load order does not exist.
+- [ ] Add `m01-learning-lab-data.js` with one reusable technique/workbook contract per M01 lesson and attach the existing validation decision drill by `lessonId`.
+- [ ] Add the script to `index.html` in the required order.
+- [ ] Run the full test suite and commit.
+
+### Task 2: Render decision lab and workbook
+
+**Files:**
+- Modify: `app.js`
+- Test: `tests/m01-app-smoke.test.js`
+
+**Interfaces:**
+- Consumes: optional `lesson.learningLab`.
+- Produces: DOM classes `learning-lab`, `lab-drill`, `lab-feedback`, `lab-workbook`, `lab-transfer`, plus persisted `state.lab[lessonId]`.
+
+- [ ] Add a failing VM/static smoke test asserting an M01 lesson includes a decision drill, feedback region, technique, workbook fields, and transfer section while a non-M01 lesson does not include `learning-lab`.
+- [ ] Verify RED with `node --test tests/*.test.js`.
+- [ ] Extend `defaultState` with `lab: {}` and normalize missing nested lab state when rendering.
+- [ ] Render the optional lab sequence before the final completion action: cold/guided decision drill → feedback → worked example → technique → workbook → transfer.
+- [ ] Bind drill radio changes to persist the selected option and render option-specific feedback immediately.
+- [ ] Bind workbook input/textarea changes to persist field values.
+- [ ] Run full tests and commit.
+
+### Task 3: Gate M01 completion on evidence instead of checkbox self-attestation
+
+**Files:**
+- Modify: `app.js`
+- Test: `tests/m01-app-smoke.test.js`
+
+**Interfaces:**
+- Produces: `labReady(lesson, state)` behavior: at least one answered drill and all required workbook fields non-empty.
+
+- [ ] Add a failing test that M01 completion is disabled until drill + required workbook fields are present, then enabled; verify a representative M02 lesson still uses the existing criteria gate.
+- [ ] Verify RED.
+- [ ] Add a small readiness helper and M01-specific completion status text.
+- [ ] Hide legacy checkbox criteria for lessons with `learningLab`; preserve them for all other lessons.
+- [ ] Update completion handler so M01 uses lab readiness and still writes to the existing `completed` array and advances to the next lesson.
+- [ ] Run full tests and commit.
+
+### Task 4: Fix readability without losing art direction
+
+**Files:**
+- Modify: `art-direction.css`
+- Test: `tests/static-contract.test.js`
+
+**Interfaces:**
+- Produces: readable essential text tokens and styled lab surfaces/classes.
+
+- [ ] Add failing CSS contract tests that essential secondary learner text uses a named readable token rather than `#5f5f5a`, `#666660`, or `#777770`, and that lab classes have explicit focus/feedback styles.
+- [ ] Verify RED.
+- [ ] Introduce `--text-secondary` and `--text-tertiary` values with visibly stronger contrast on `#0a0a0a`.
+- [ ] Replace low-contrast essential labels/statuses with the new tokens while leaving decorative numbering subdued.
+- [ ] Style `learning-lab`, drill options, feedback, technique, workbook, transfer, and focus states in the Editorial Instrument language.
+- [ ] Ensure body/workbook text remains at least 16px where substantive.
+- [ ] Run full tests and commit.
+
+### Task 5: Integration verification and clean Pages preview
+
+**Files:**
+- Production assets only on `gh-pages` after feature CI is GREEN.
+
+- [ ] Run/confirm `Prototype CI` on the final feature head and require success.
+- [ ] Build a clean `gh-pages` tree from current production assets plus the new lab data/app/style/index files; do not copy tests/docs into Pages.
+- [ ] Verify Pages deployment success for the exact deploy SHA.
+- [ ] Externally fetch root and first M01 lesson to confirm the new scripts/content are publicly served.
+- [ ] Open a PR from `feature/m01-learning-lab` to `feature/art-direction-editorial-instrument`; do not merge.
diff --git a/docs/superpowers/plans/2026-09-09-m01-playable-vertical-slice-implementation.md b/docs/superpowers/plans/2026-09-09-m01-playable-vertical-slice-implementation.md
new file mode 100644
index 0000000..f41a475
--- /dev/null
+++ b/docs/superpowers/plans/2026-09-09-m01-playable-vertical-slice-implementation.md
@@ -0,0 +1,293 @@
+# M01 Playable Vertical Slice Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Implement one deterministic 7–10 minute M01 project-management simulator mission with four decisions, visible project state, optional tools, authored consequences, trajectory review, and cohort-safe evidence persistence.
+
+**Architecture:** Keep the existing static-app architecture. Add one authored mission data module, one pure deterministic simulator domain module, and one simulator UI extension that owns `#/mission/m01`. Integrate minimally with `index.html`, the base router reservation, M01 course entry point, and M01 validation treatment gate; preserve baseline/post-case isolation and keep all simulator evidence in a dedicated localStorage key.
+
+**Tech Stack:** Vanilla HTML/CSS/JavaScript, browser localStorage, Node 22 built-in test runner (`node --test`).
+
+**Spec:** `docs/superpowers/specs/2026-09-09-m01-playable-vertical-slice-design.md`
+
+## Global Constraints
+
+- M01 only; no M02 changes.
+- No telemetry changes.
+- Do not modify `main`; work only on the isolated feature branch.
+- No production publication or merge.
+- Mission ID is `m01-mission-partner-launch-v1`.
+- Simulator storage key is exactly `pm01-sim-m01-v1`.
+- Runtime committed decisions are an append-only `decisions[]` array.
+- Exactly four deterministic decision moments; no randomness and no hidden aggregate score.
+- Visible project state: deadline confidence, stakeholder trust, team capacity, launch risk, each clamped to `0..100`.
+- Optional tools are penalty-free and never reveal the preferred answer.
+- First committed choice at each decision is immutable for cohort evidence.
+- Baseline/post-case remain separate and blind; simulator completion unlocks post-case only for the pinned simulator treatment.
+- Do not mix old textual M01.1 treatment evidence with simulator-treatment evidence inside one cohort.
+- No automatic mastery inference.
+- Accessibility is part of the slice: semantic controls, keyboard path, focus management, text equivalents for meters, reduced-motion compatibility.
+
+---
+
+## File Structure
+
+- Create `m01-simulator-data.js` — authored mission content, initial state, four decisions, tools, copy, deterministic deltas and flags.
+- Create `m01-simulator-domain.js` — pure state/evidence functions: initial state, transition, clamping, completion, trajectory summary.
+- Create `m01-simulator-app.js` — route renderer, persistence, tool interaction, decision commit, consequence screen, trajectory review.
+- Create `m01-simulator.css` — simulator-only styles and accessibility states.
+- Modify `index.html` — load simulator CSS/data/domain/app in deterministic order.
+- Modify `app.js` — reserve `mission/m01` from base-router overwrite and route the M01 course entry point to the mission while leaving non-M01 modules unchanged.
+- Modify `m01-validation-app.js` — replace the two-lesson learning gate with the pinned simulator mission completion gate on this feature branch; leave baseline/post/field/reflection logic intact.
+- Create `tests/m01-simulator-domain.test.js` — pure deterministic transition/evidence tests.
+- Create `tests/m01-simulator-integration.test.js` — static/VM contract tests for route ownership, load order, treatment isolation, first-choice lock and accessible markup.
+
+---
+
+### Task 1: Define simulator domain contract with RED tests
+
+**Files:**
+- Create: `tests/m01-simulator-domain.test.js`
+- Create: `tests/m01-simulator-integration.test.js`
+
+**Interfaces:**
+- Consumes: existing Node test conventions and browser-global module pattern.
+- Produces required interfaces for later tasks:
+ - `window.PM01SimulatorData.mission`
+ - `window.PM01SimulatorDomain.initialRun(mission)`
+ - `window.PM01SimulatorDomain.commitDecision(run, mission, decisionId, optionId, rationale)`
+ - `window.PM01SimulatorDomain.openTool(run, toolId, decisionId)`
+ - `window.PM01SimulatorDomain.isComplete(run, mission)`
+ - `window.PM01SimulatorDomain.trajectory(run, mission)`
+
+- [x] **Step 1: Write failing pure-domain tests**
+
+Test that the mission has exactly four decisions, every decision has 3–4 options, all effects are deterministic integers, initial meters are `0..100`, transitions clamp meter values, committed decisions cannot be replaced, tool opening records evidence without changing meters, and completion requires exactly four committed decisions plus required rationales for D1/D4.
+
+- [x] **Step 2: Write failing integration/static tests**
+
+Test that `index.html` loads simulator data → domain → app after base learning data but before validation extension; the base router reserves `mission/m01`; the simulator app owns `#/mission/m01`; validation uses the simulator completion contract instead of legacy lesson completion on this branch; simulator storage uses a dedicated key and does not write telemetry.
+
+- [x] **Step 3: Run tests and confirm RED**
+
+Run: `node --test tests/m01-simulator-domain.test.js tests/m01-simulator-integration.test.js`
+
+Observed in CI #147: expected FAIL because simulator files/interfaces/wiring do not yet exist; existing tests remain green.
+
+- [x] **Step 4: Align RED contract with approved spec before production code**
+
+Corrected the storage key to `pm01-sim-m01-v1` and the runtime decision contract to append-only `decisions[]` before GREEN implementation.
+
+---
+
+### Task 2: Implement authored mission data + pure transition engine
+
+**Files:**
+- Create: `m01-simulator-data.js`
+- Create: `m01-simulator-domain.js`
+- Test: `tests/m01-simulator-domain.test.js`
+
+**Interfaces:**
+- `PM01SimulatorData.mission` includes `id`, `version`, `title`, `initialState`, `meters`, `tools`, `decisions`.
+- `initialRun(mission)` returns `{ treatmentId, missionVersion, status, decisionIndex, meters, flags, decisions: [], toolsOpened: [], events: [] }`.
+- `commitDecision(...)` returns a new run object and rejects an invalid node/option or a second commit to the same node.
+- `openTool(...)` returns a new run with one evidence event and unchanged meters.
+- `trajectory(...)` returns a deterministic review model from the run; no hidden aggregate score.
+
+- [ ] **Step 1: Implement mission data exactly from the approved spec**
+
+Use initial meters: deadline 58, trust 64, capacity 72, risk 63. Implement D1–D4 options, deterministic meter deltas and flags from the spec, plus the three optional tools: Decision Timeline, Hypothesis Comparator, Change Condition.
+
+- [ ] **Step 2: Implement pure immutable domain functions**
+
+Clamp meters to `0..100`. Append decision records containing `decisionId`, `optionId`, rationale, state before/after, delta and flags added. Do not use time or randomness in domain decisions; timestamps are UI persistence metadata only.
+
+- [ ] **Step 3: Run pure-domain tests**
+
+Run: `node --test tests/m01-simulator-domain.test.js`
+
+Expected: PASS.
+
+- [ ] **Step 4: Run full existing test suite**
+
+Run: `node --test tests/*.test.js`
+
+Expected: existing tests plus simulator-domain tests pass except integration tests that intentionally wait for Task 3/4 wiring.
+
+- [ ] **Step 5: Commit**
+
+Commit message: `feat: add deterministic M01 simulator mission engine`
+
+---
+
+### Task 3: Build accessible playable mission UI and persistence
+
+**Files:**
+- Create: `m01-simulator-app.js`
+- Create: `m01-simulator.css`
+- Modify: `index.html`
+- Test: `tests/m01-simulator-integration.test.js`
+
+**Interfaces:**
+- Route: `#/mission/m01`.
+- Dedicated storage key: `pm01-sim-m01-v1`.
+- Stored envelope: `{ treatmentId, missionVersion, run, startedAt, completedAt, reviewReachedAt }`.
+- Completion evidence must expose the pinned treatment ID `m01-mission-partner-launch-v1` and require the trajectory review to have been reached/persisted.
+
+- [ ] **Step 1: Load simulator modules and CSS in `index.html`**
+
+Load `m01-simulator-data.js`, then `m01-simulator-domain.js`, then `m01-simulator-app.js`; keep `m01-validation-app.js` last so it can consume the completion contract.
+
+- [ ] **Step 2: Render mission shell**
+
+Render title/premise, textual meter cards, progress `Decision N of 4`, open facts, optional tools and current decision as semantic `