Atlas expansion plan¶
English · Русский · Coverage audit · Learning roadmap
Plan date: 2026-10-05. This is the implementation backlog for the research and learning expansion, subordinate to the repository-wide roadmap and methodology. Priorities express dependencies and value, not promised dates. The initial P0 documentation scope was extended to all identified content work: source corrections, questions where provenance permits, answers, primary reading and explanation/case checklists. Python exercises, executable labs, project implementation and an AI evaluator are deferred by the maintainer. No new schemas or CLI are included.
The two canonical tracks remain Engineering and Leadership. Focused routes, responsibility branches and original curriculum cases do not become new tracks or inflate the question bank. Published questions still require interview evidence; radar-generated questions still follow the existing provenance contract. Appearing in a guide does not give an editorial drill either provenance category.
P0 — make the decisions and practice reviewable¶
Status: the documents and navigation are implemented. The original acceptance criteria below remain the review contract; the current content phase is described under P1–P3 and in the audit addendum. Independent review and final repository checks are separate gates, not claims of publication or successful learner trials.
| Item | Deliverable and acceptance | Dependency / evidence |
|---|---|---|
| P0.1 — reproducible coverage audit | Overall audit with snapshot counts, scope and limitations; Leadership audit with all-question semantic review and a clearly bounded 20-question source check | Existing YAML bank; exact question IDs; private working evidence retained separately. Count overlap correctly; distinguish 70 Leadership priorities from 89 answer-bearing entries |
| P0.2 — source-bounded Engineering research | Report inventories 30 Hello Interview entries and identifies accessible excerpts, Premium limits and two unavailable bodies; separates unsourced map input from independent sources | Public guide and roadmap plus primary provider, OWASP and MCP checks. Do not copy paid explanations or publish supplied images |
| P0.3 — focused Engineering routes | Four-week coding route and eight-week service route, each with entry check, workload, original outputs, failure cases and delayed gates | P0.2 and existing stable anchors. Cover seven algorithm families; contracts, evals, retrieval, tools, operations and authority. No runnable code or automatic evaluator implied |
| P0.4 — Leadership practice supplement | Eight-week route with Product, EM/Platform, Head/Director and TPM/Delivery emphases; separate real stories from fictional decisions | P0.1. Budget/portfolio and organisation cases are explicitly editorial; no automatic promotion of PM/EM or Senior Staff+ evidence to Director/TPM |
| P0.5 — coherent navigation and language parity | Learning roadmap, EN/RU mirrors and links from generated discovery pages/site navigation; preserve the current eight-week baseline | P0.1–4. No manual edits to generated pages; verify relative links, anchors, route duration, thresholds and limitations in both languages |
| P0.6 — independent review and repository checks | A separate flagship review from every author/editor; all material findings resolved or explicitly left open. Required code, generated-content, strict-site and privacy checks pass before handoff | All P0 files at the reviewed revision; preserve previous authorship/review records. Passing checks does not publish the site or books |
P1 — correct content and refine practice criteria¶
Content implemented; final independent review is a separate gate. The original priorities are retained to show the approved sequence. P1.1 corrects the three source adaptations while retaining the unavailable Meta report as unresolved; P1.2–3 provide Leadership cases and coding explanations with failure criteria. P1.4 is editorial consistency review, not empirical calibration with learners. The criteria below describe what the changes must satisfy.
| Item | Acceptance criterion | Dependency / reason |
|---|---|---|
| P1.1 — source adaptation corrections | Re-read the sources for lead-low-performance, lead-disruptive-star and lead-reorganisation-retention; align prompt/type or expose adaptation, preserving IDs and EN/RU parity. Recheck prog-cross-team-delivery only through permitted public access; retain an explicit unresolved status if unavailable |
Leadership audit found hypothetical/behavioural and scenario mismatches plus one unavailable report. Requires source-of-truth YAML review and regeneration |
| P1.2 — Leadership supplement and criteria | Refine the P0 cases across Product, EM/Platform, Head/Director and TPM/Delivery into clear decision briefs with inputs, authority, expected artifact, failure conditions and 0–3 criteria. Keep hypothetical work separate from real experience | P0.1 and P0.4. Portfolio, budget and organisation cases remain editorial; existing source limitations stay visible. Independently review the specifications before making case packs |
| P1.3 — AI-assisted coding method | Specify orientation, bounded context, decomposition, algorithm choice, verification, PR review and defence as an observable workflow. For each step give an acceptance probe and a meaningful failure example; retain restricted-tool and AI-permitted variants | P0.2 and P0.3. Use original tasks and the seven-family map, not paid problem reconstructions; do not infer universal employer permission |
| P1.4 — assessment consistency | Walk through representative hypothetical artifacts with independent reviewers; clarify ambiguous instructions and rubric thresholds. Specify what tests, source checks or human judgement can establish before implementing a lab | P1.2–3. This is a specification review, not a learner trial or a validation of hiring predictions |
P2 — implement two local labs, a production project and checkable cases¶
P2.1–3 and P2.5 are deferred by the maintainer. Their acceptance criteria are retained as future scope, not current learner assignments. If resumed, the two labs must be local Python exercises requiring no API keys; deterministic fixtures and stubs must support acceptance without model calls. P2.4 is content-only and belongs to the authorised case supplement; it does not depend on implementing the labs.
| Item | Acceptance criterion | Dependency / reason |
|---|---|---|
| P2.1 — local Python lab 1: bugfix and bounded feature | Implement the original boundary-bug/batch exercise with a baseline, task contract and meaningful correctness tests. Cover expiry boundaries, empty input, duplicate IDs and ordering. Run from a clean local environment without API keys | P1.3–4. Tiny synthetic or suitably licensed repository; inspect every supplied file for privacy. Independently review task and solution; document manual, restricted-AI and AI-permitted practice modes |
| P2.2 — local Python lab 2: algorithm and PR review | Supply a small original change with an invariant or access-check defect. Require a justified algorithm choice, counterexample, regression test and review decision. Use synthetic fixtures and local tests without API keys | P1.3–4. Cover meaningful wrong solutions, memory/runtime limits and a delayed variant; do not ship a paid problem reconstruction or require an external model service |
| P2.3 — production AI engineering project | Implement the synthetic catalogue capstone from baseline through contracts, evaluation, access-filtered retrieval, bounded tools, operations and release defence. Include deterministic model/service stubs and a reproducible no-key path | P0.3 and P1.4. Tests expose wrong evidence IDs, denied access, timeout-after-action, duplicate execution and hard-budget stop. Held-out cases are not used for tuning. Separate control-flow checks from live-model quality and injection resistance; no real external actions |
| P2.4 — checkable Leadership cases | Produce case packs for the four branches with synthetic inputs, decision constraints, arithmetic that can be checked, expected artifacts and example feedback. Include portfolio/budget, build/buy, organisation change and delivery re-planning | P1.2 and P1.4. Accept defensible alternatives rather than one model answer; specify critical failure and stop conditions, truthfulness boundaries and a delayed variant |
| P2.5 — human pilot and calibration | Run a small consented pilot of the two labs, project and selected cases; record time, unclear instructions, artifact failures and independent reviewer disagreements. Revise workload and criteria from those observations | P2.1–4. Keep participant material private and publish only non-identifying findings. For optional live-model trials record configuration, repetitions and uncertainty; a usability pilot does not validate hiring outcomes |
P3 — expand practice, reading and independent evidence¶
The current content phase completes the identified reading gaps and selected answer coverage under P3.2. P3.1 now uses additional conceptual questions, failure probes and Leadership cases; further labs remain deferred. P3.3 records the evidence search and its unresolved limits: technical references do not provide independent company corroboration. P3.4 remains a separate book/export decision.
| Item | Acceptance criterion before adoption | Dependency / reason |
|---|---|---|
| P3.1 — expanded practice | Current content adds conceptual follow-ups, counterexamples and case criteria. Any additional executable labs require renewed scope; preserve the competence map, failure probes, feedback examples and EN/RU parity | Current source/coverage audit; a later pilot may inform further changes. Avoid near-duplicates; editorial examples remain distinguishable from interview-bank questions |
| P3.2 — remaining reading and answers | Filled the initial reading gaps across the bank, including 37 Leadership-tagged entries, and added 18 EN/RU answers to selected priority questions. All current questions have reading; other outline-only questions remain elective answer-expansion candidates | P1 corrections and source-fit checks; content does not depend on running deferred labs. Reading strengthens teaching, not interview attribution; never invent a professional story, unsupported result or level |
| P3.3 — independent company corroboration | Seek official interview material and dated first-hand accounts, especially for Head/Director and AI TPM. Record role, authority/scope, date, access and publisher independence; re-read concentrated or ageing claims | Audit evidence gaps and existing freshness work. A posting cannot prove a question; two pages from one publisher are not independent corroboration. Record unavailable or absent evidence instead of claiming coverage |
| P3.4 — printable expansion | Decide whether to include the new guides and reviewed practice in books; regenerate after content review, check extracted text and inspect every rendered page | Stable reviewed content and existing PDF workflow. Local artifacts are not released assets; publication is a separate maintainer decision |
An optional AI feedback tool remains deferred beyond the current iteration and is not required for P1 or P2. Before considering it, establish reviewed human examples, disagreement and critical-failure checks, contestable feedback, and retention, cost and prompt-injection boundaries. It must not turn a model score into a hire/no-hire verdict or claim validated proficiency. Exercise export, new schemas/CLI and a progress interface likewise require a demonstrated need and separate scope; the manual route remains usable without them.
Work allocation and review¶
For future work in this expansion, use gpt-6.1-sol for engineering implementation and routine code checks, gpt-6-astra for complex public prose, semantic audit and independent final content review, and gpt-6-luna for bounded extraction and mechanical checks. These are task assignments, not claims about comparative prices or benchmark capability. Use no more than four concurrent agents, and parallelise only disjoint files or read-only tasks. Keep dependencies and integration sequential.
The final content reviewer must be a separate session from every author/editor of the reviewed public prose. A self-check or a second label for the same session does not qualify. Follow the active environment's flagship requirement; a missing required model blocks that task rather than being relabelled. Preserve prior Claude and other authors' records. Actual model/session identities, source-check details and review evidence belong in private working records, not invented public authorship claims.
Every implementation handoff runs the checks required by CONTRIBUTING: lint/format, tests, generated-content check, strict site build, and privacy checks for worktree, index and history. Stage explicit paths only. Scope changes, unresolved source gaps and failed gates remain visible. The maintainer separately decides whether to publish or release a reviewed result.