Skip to content

Content Blueprint

This repository should grow in layers, not as a random pile of solutions.

What Every Mature Topic Should Ship

Each finished topic should eventually include:

  1. a layered, self-contained tutorial page in topics/
  2. one or more reusable implementations in templates/ or solutions/
  3. a small practice ladder in practice/ladders/
  4. a go deeper block with:
  5. one primary or course link
  6. one reference link
  7. one practice link
  8. one optional essay / blog link when it adds real insight

If the topic includes visuals, those visuals should also satisfy Visual Content Contract, not just exist as a decorative extra.

Writing Rule

Each mature topic page should open with a fast-scanning core path, but the full page should still be complete enough that a serious reader can learn the topic without hunting for another primary explanation.

At minimum, the page should answer:

  1. When do I use this?
  2. What is the brute-force baseline, and why does it fail?
  3. Why does the optimized algorithm work?
  4. What are the important variants and tradeoffs?
  5. What is the clean implementation pattern?
  6. What should I solve next?

Anchor topics should also include:

  • one real proof or correctness invariant
  • two worked examples
  • pseudocode plus implementation notes
  • a variant chooser
  • practice archetypes with recognition comments

When a visual layer is present on an anchor topic, the default target should be:

  • one orientation visual
  • one mechanism visual
  • one explicit bridge from the visual back to code and boundaries

Not every page has the same role:

  • technique leaf: full deep tutorial for one concrete algorithm or data structure
  • family / chooser page: a decision map across multiple related algorithms
  • theory-led page: concept, theorem, or modeling page where code is secondary

The full deep template is the default for technique leaf pages. Family and theory-led pages may compress or rearrange sections, but they should still preserve the same teaching promises.

Canonical mature technique leaf examples in this repo:

Before writing a new deep topic page, copy the pacing and section depth from one of those two pages instead of starting from a blank outline.

For references, use this taxonomy consistently:

  • Primary: paper, official docs, or source-closest record
  • Course: lecture notes or slides
  • Reference: contest-friendly reference page
  • Essay / Blog: optional intuition or derivation piece
  • Practice: official platform/archive
  • Repo anchors: internal ladder, template, notebook, note

Cross-Cutting Sourcing And Freshness Contract

Every serious content pass should start with a small research sweep, not only a writing pass.

Use this two-way split for every page or content artifact:

  • Evergreen: the main ideas should stay stable for years, but the page still needs strong supporting sources
  • Freshness-sensitive: official docs, platform behavior, judge workflow, build/deploy details, or recommendations could change and must be rechecked

Evergreen Rule

Examples:

  • most algorithm topic pages
  • proofs, derivations, and math-heavy explanations
  • reusable templates
  • most solved notes and ladders

Requirements:

  • perform a research sweep before calling the page mature
  • prefer Primary, Course, and Reference sources for definitions, facts, and proofs
  • add Essay / Blog only when it materially improves intuition, derivation, or implementation judgment
  • do not assume the page can skip online research just because the topic is old

Freshness-Sensitive Rule

Examples:

  • contest playbooks
  • toolchain guidance
  • compile / debug / sanitizer workflow notes
  • route pages that recommend external resources
  • docs about judges, libraries, platforms, or official curricula

Requirements:

  • verify the relevant official or primary online sources during the pass
  • record a snapshot or last reviewed date in the governing maintainer doc or the page itself when the date matters
  • if the pass belongs to a source-family lane or route/workflow page, record or refresh the corresponding entry in Freshness Backbone
  • prefer official documentation and project-primary links over secondary summaries
  • if the page contains recommendations, commands, or tool behavior that might drift, treat online verification as mandatory

Layer-by-Layer Minimum

  • topics/: source-backed before a page becomes mature; math/proof topics should still be researched, not written from memory alone
  • templates/: every nontrivial template should be backed by at least one strong topic page or primary/reference source
  • notebook/: short pages can stay compact, but the underlying claims should trace back to a researched topic page or workflow source
  • practice/: ladders and notes should use researched topic understanding plus official problem/judge links where relevant
  • docs/: route pages, playbooks, and maintainer docs should be the strictest about freshness when they recommend current external resources or workflows

Default Rule For Future Passes

Before expanding any content family, do this in order:

  1. identify whether the pass is evergreen or freshness-sensitive
  2. gather the minimum online sources first
  3. write the page in repo voice
  4. store the evidence in the page or in a maintainer-facing companion doc
  5. only then call the content complete

Build Order

Use stages as the progression language across the repo. This file is the maintainer-facing build plan, not a second public taxonomy.

Stage 0: Foundations

Build first:

  • C++ setup and STL patterns
  • asymptotic analysis
  • proof tools: induction, invariants, exchange arguments
  • sorting, binary search, prefix sums, two pointers

Deep links:

Stage 1: Data Structures

Build next:

  • DSU
  • Fenwick tree
  • segment tree
  • sparse table
  • heaps and ordered sets

Deep links:

Stage 2: Graphs

Build next:

  • BFS / DFS
  • shortest paths
  • MST + DSU
  • SCC + topological sort
  • trees, LCA, rerooting basics
  • flow and matching

Deep links:

Stage 3: Dynamic Programming and Math

Build next:

  • classic state design
  • knapsack family
  • bitmask DP
  • tree DP
  • digit DP
  • modular arithmetic
  • combinatorics
  • number theory core

Deep links:

Stage 4: Strings and Geometry

Build next:

  • hashing
  • KMP, Z-function
  • trie, Aho-Corasick
  • suffix array / automaton
  • vectors, orientation, convex hull
  • line sweep and intersection basics

Deep links:

Stage 5: Advanced Theory

Build after the core is stable:

  • randomized algorithms
  • approximation
  • LP duality
  • spectral / convex ideas
  • complexity and hardness
  • algorithm engineering

Deep links:

Stage 6: Contest Engineering

Build continuously:

  • notebook standards
  • stress testing
  • generators
  • debugging checklist
  • upsolving workflow
  • team contest playbook
  • contest-track roadmaps

Deep links:

Deliverable Shape By Folder

  • topics/: layered teaching pages with a scannable core path and a deeper tutorial layer
  • templates/: reusable contest-ready code
  • practice/ladders/: topic-first problem ladders
  • practice/mixed-rounds/: review packs that mix topics
  • practice/contest-playbooks/: contest-specific prep guides
  • notebook/: curated snippets and team-reference material

Minimum Viable Standard

Before calling a topic "done", make sure it has:

  • one main explanation page
  • one clean implementation
  • three to ten practice problems
  • one go deeper block with source links