Developer — system_prompt
Behavior rules for this folder, layered on top of README.md's global rules per its "System Prompts Per Project/Feature" table. Read this immediately after the README whenever working inside Developer/.
Purpose
A knowledge base for hands-on Developer + DevOps fundamentals, real-world case studies, design/debugging challenges, and reusable checklists — the tactical, code-and-operations layer that complements Architecture/'s system-design layer. Where Architecture/ targets Principal-level system-design judgment, Developer/ targets day-to-day engineering craft: language/runtime depth, testing discipline, CI/CD, cloud/infra-as-code mechanics, observability, debugging, and application security. Applies to development generally, not just current work — hence living under Developer/ rather than being scoped to a single project like LocalzDocs/.
Structure: topic-first, not flavor-first
Revised 2026-08-24 — the original flavor-first design (top-level Fundamentals//CaseStudies//Challenges//Checklists/ folders bucketed by a 7-item pillar tag) never got populated and was replaced before any content existed. The folder is topic-first instead:
Developer/
<Topic>/ e.g. AI, Auth, Networking, Security, Languages, ...
README.md Why / When / How / Subtopics / Research questions
<Subtopic>/ e.g. Languages/Python/Concurrency
README.md Why / When / How / Research questions (same shape)
Fundamentals/ one file per timeless concept note (kebab-case filename)
CaseStudies/ one file per real-world breakdown
Challenges/ one file per hands-on scenario
Checklists/ one file per reusable checklist
Revised again 2026-08-24 (same day) — each flavor is a directory, not a single accumulating file, matching Architecture/'s proven per-note-file convention exactly. A single file per subtopic/flavor was tried first and abandoned before the scheduler's second run: a subtopic can accumulate many entries over the 8-week sprint and beyond, and one large file per flavor becomes unwieldy to edit, link into, and diff in git. Each flavor directory is created lazily — only when the first note for that subtopic/flavor combination exists. A subtopic with only a Fundamentals/ folder and no Checklists/ yet is normal, not a gap to fill on principle; not every subtopic has genuine checklist material.
Filenames within a flavor directory: kebab-case, derived from the note's title (e.g. Auth/SecretManagement/Fundamentals/secrets-management-and-rotation.md) — same convention as Architecture/.
Topic folders present today: AI, Analytics, APIDesign, AppIntegration, ArchitecturePatterns, Auth, Availability, BusinessValue, CommunicationPatterns, Compliance, Compute, ConsistencyConcurrency, Containers, CostManagement, DataFlowPatterns, DataManagement, DesignPatterns, DeveloperTools, FrontendWebMobile, Geospatial, Governance, Idempotency, Languages (Python, Go, TypeScript), MachineLearning, MigrationTransfer, Networking, Observability, RateLimiting, RecordsAudit, Regulatory, SchedulingQueueingDisciplines, Security. New topics/subtopics can be added by hand any time — this list is not meant to be exhaustive or final.
General theory vs language-specific application: where a concept has both a language-agnostic home and a language-specific one (e.g. concurrency theory in ConsistencyConcurrency/Concurrency-Threading/ vs Python's GIL/asyncio specifics in Languages/Python/Concurrency/), keep theory in the general topic folder and cross-link from the language-specific subtopic rather than duplicating it. Same pattern for FrontendWebMobile/ (general) vs Languages/TypeScript/FrontendFrameworks/ (React/Next.js-specific).
Indexing: two-tier, split 2026-08-24 — always kept current
Split preemptively on 2026-08-24, before the flat single-index file got unwieldy — same reasoning as the flavor-directory split above, applied one level up. Two tiers:
Developer/<Topic>/_index.md— one per topic, full note listing grouped by subtopic (## <Subtopic>headers, one- <Flavor> — [[relative/path\|Title]]bullet per note). This is where every new note gets indexed.Developer/_index.md(the hub) — a## Full topic tree: every topic → subtopic → sub-subtopic folder, nested by indentation, each leaf carrying a note count or*(empty)*. Never lists individual notes/titles — those live only in the topic-level index. Populated topics also link their[[Topic/_index\|index]].
Both are kept in sync with reality at all times, by anyone who touches Developer/ — the scheduler on every automated run (see developer-scheduler step 7), and equally by any manual/interactive edit: a new note, a new subtopic folder, a renamed/removed note, or a topic going from empty to non-empty all require updating the topic index and the hub tree (counts rolled up to every ancestor) in the same change. Treat "add a note" and "update its indexes" as one atomic edit, not a followup. A topic without an _index.md yet gets one created — matching an existing topic's format — the first time it receives a note.
Flavor content, one file per note
Fundamentals/<slug>.md — Concept, Tradeoffs (a comparison table where the topic genuinely has competing approaches, not forced), When to use / when not to, Common pitfall, ## Engineering Lens, ## Sources (real URLs used — omit only for a self-evidently timeless CS concept with no external research), ## Related.
CaseStudies/<slug>.md — Problem + constraints, Solution, What to steal, ## Engineering Lens, ## Sources (the real source URL(s) — a CaseStudy is never self-written), ## Related.
Challenges/<slug>.md — Scenario prompt, Mihir's attempt (> [!todo] placeholder if not yet written — never fabricated), Model solution, Gaps to revisit, ## Engineering Lens, ## Related.
Checklists/<slug>.md — Purpose, the checklist itself (task list, grouped by phase if long), common failure modes it guards against, ## Engineering Lens, ## Related.
Every note is its own file with its own frontmatter (title, tags, source, created) at the top, then plain ## section headings as listed above (not demoted — each file is self-contained, same as Architecture/'s notes). tags should include the subtopic's relevant pillar-* tag(s) below.
Depth bar — calibrated against Architecture/
Architecture/'s existing notes (e.g. Fundamentals/circuit-breaker-pattern.md) are the proven quality bar this folder must match, not just structurally but in research effort: roughly 600-1200 words per Fundamentals/CaseStudies entry, a real tradeoff table where the concept has genuine competing approaches, a concrete walked-through scenario (not abstract description), and real cited sources — not summary-level stub paragraphs. Fewer, deeper entries beat more, shallower ones — a run that writes 2 Architecture-grade entries did more real work than one that writes 8 thin ones. Never pad to hit a quota; never fabricate a Sources link.
Coverage rotation — added 2026-08-25
Supersedes the old "picks fully-untouched subtopics first" breadth heuristic. With 255 leaf subtopics, picking freely gave no guarantee that every subtopic got covered before some got revisited — this rotation guarantees a complete sweep of all 255, one flavor at a time, in a fixed order, before starting the next sweep. Full state (current pass, cursor, skip/revisit logs) lives in writelist — read that section every run; this is the reference for the mechanics only.
Canonical order: all 255 leaf subtopics (a folder with no further subtopic subfolders below it — the level that would directly hold Fundamentals//CaseStudies//Challenges//Checklists/), walked topic-alphabetically then subtopic-path-alphabetically within each topic. Same order Developer/_index.md's ## Full topic tree renders in. Never hardcode this list anywhere (writelist.md deliberately doesn't) — recompute it by walking the filesystem each run, so newly added subtopics slot in automatically.
10 fixed passes, each one flavor swept end-to-end across all 255 in canonical order, in this exact sequence: Fundamentals, CaseStudies, Challenges, CaseStudies, Challenges, CaseStudies, CaseStudies, Challenges, Fundamentals, CaseStudies. Checklists is never part of the rotation — stays opportunistic, same as always (never required, never blocks a pass).
Per-run mechanics: read writelist.md's current_pass/current_flavor/pass_cursor. Starting immediately after pass_cursor in canonical order, attempt subtopics for current_flavor up to the run's normal note cap (still ≤4/run, still "2-3 is normal, never stretch to hit a quota" — the rotation changes which subtopic/flavor gets picked, not the per-note quality bar or per-run cap). A subtopic that can't clear the depth bar for this flavor gets logged to writelist.md's "Skipped this pass" and the cursor still advances past it — a pass completing with some gaps is expected, not a failure; see developer-scheduler for the exact read/write steps.
Pass completion: when the cursor reaches and processes the last leaf in canonical order, advance current_pass to the next row in the table (wrapping "Skipped this pass" into the cumulative "Revisit log" first), reset the cursor. After pass 10 completes, rotation ends — current_pass becomes the literal string random and stays there; the scheduler reverts to unconstrained picking across any topic/subtopic/flavor by best-available material, same as the original pre-rotation design. Do not restart the 10-pass sequence.
Pillar tags (three vocabularies, not folder structure)
Every note carries at least one pillar-* tag (usually one craft + one design/domain tag) in its frontmatter so cross-cutting patterns stay visible regardless of which topic folder it lives in. Three vocabularies, kept separate rather than collapsed into one list — they answer different questions and a note can need any combination:
Craft pillars — "what kind of engineering skill":
| Pillar tag | Covers |
|---|---|
pillar-languages-runtimes |
Language internals, memory/concurrency models, standard library idioms, runtime performance |
pillar-testing-quality |
Unit/integration/e2e testing, TDD, mocking, coverage, static analysis, code review practice |
pillar-ci-cd-release |
Build pipelines, release strategy, versioning, rollback, deployment automation |
pillar-cloud-infra-iac |
Terraform/CDK/Ansible, containers, Kubernetes, cloud provisioning mechanics |
pillar-observability-debugging |
Logging, tracing, metrics, profiling, root-causing production issues |
pillar-security-appsec |
Secure coding, dependency/supply-chain hygiene, secrets management, OWASP-class bugs |
pillar-collaboration-workflow |
Git workflows, code review culture, documentation, dev environment/tooling ergonomics |
Design pillars (inherited from Architecture/'s taxonomy, kept as-is on migrated notes) — "what design concern":
| Pillar tag | Covers |
|---|---|
pillar-security |
Threat modeling, defense in depth, zero trust, encryption |
pillar-resilience |
Fault tolerance, circuit breakers, chaos engineering, disaster recovery |
pillar-performance |
Latency, throughput, caching, indexing, algorithmic complexity in a system-design context |
pillar-cost |
Cloud cost optimization, FinOps, pricing-model tradeoffs |
pillar-operational-excellence |
SLOs, observability at the system level, postmortems, deployment safety |
pillar-org-complexity |
Conway's law, team topologies, cross-team architectural decision-making |
Domain pillars (added 2026-08-24 — the first two vocabularies left real gaps: notes under Governance//Compliance//Regulatory//RecordsAudit/ and under DataManagement/DataEng/AI//MachineLearning/ had nothing that actually fit) — "which specialization this falls under":
| Pillar tag | Covers |
|---|---|
pillar-dsa |
Data structures & algorithms, complexity analysis, interview-style problem solving — the DesignPatterns/AlgorithmsDataStructures/ tree |
pillar-grc |
Governance, risk & compliance — regulatory frameworks, audit, policy, architecture governance |
pillar-data-engineering |
Data pipelines, warehousing, data lakes, ETL/ELT at scale |
pillar-ai-ml |
AI/ML engineering — model training, feature engineering, agentic systems, LLM integration |
pillar-frontend-mobile |
Frontend/mobile engineering — component architecture, rendering, state management, accessibility |
Add a new domain pillar only when a genuine gap shows up again (a topic where neither craft nor design tags fit) — don't add one speculatively for a topic that already tags cleanly.
Filenames: kebab-case, no spaces
Topic/subtopic folder names use PascalCase (matching what's already on disk, e.g. Languages/Python/Concurrency/) — this deviates from the plain-file kebab-case convention below, which still applies to filenames only. Flavor directory names themselves are fixed (Fundamentals/, CaseStudies/, Challenges/, Checklists/, plus README.md at the subtopic level) — the kebab-case rule applies to every note file inside a flavor directory (e.g. Auth/SecretManagement/Fundamentals/secrets-management-and-rotation.md), and to any other supporting file dropped in a subtopic folder outside the flavor directories (e.g. Languages/Python/Concurrency/concurrency_and_scalability_checklist.md).
Scheduler
See developer-scheduler — a cloud routine created 2026-08-24, running 2x/day for an 8-week enrichment sprint (through ~2026-10-19), during which every other content-generating routine in the vault is paused. Drops to a slower, depth-focused cadence after the sprint per that doc's "After the sprint" section.
Dedup
Same pattern as Architecture/: a _sources.md log should be created the first time CaseStudies/Challenges research actually happens, tracking every source URL already covered.