Inheriting a Live System: Maintenance as a Discipline.

You're taking over a three-year-old platform from the developer who built it, alone, with no documentation. Rustam Karimov runs a forty-person silk textile workshop in Margilan, Uzbekistan. His developer, Dilnoza, leaves in four weeks — and she is the only person who understands how the system works.

The discipline skills: reading code you didn't write; reverse-engineering architecture from a running codebase and a departing developer; assessing an inherited test suite with mutation testing; diagnosing a slow catalog search against the actual mechanism; walking an incident-diagnosis path through thin observability on a real export-document bug; fixing broken mobile pages without degrading the desktop layout the workshop's primary buyers depend on; triaging an inherited security posture; writing handover documentation organised by the operations the next maintainer will perform. No discipline column climbs. Every one of them changes its expression — from building to maintaining.

The AI-direction lesson: AI's defaults are most dangerous on inherited code, and the directing skill is restraint. AI's first instinct on a slow search is to propose a rewrite in a modern stack. On broken mobile pages, a fresh component library. On a malformed export document, a re-architecture of the export pipeline. For a workshop that depends on the system every day and has one developer leaving, every one of those instincts is wrong. The right answer is almost always the smallest fix that addresses the largest contributor to the symptom, with a guardrail installed against the next regression. AI is also confidently wrong when it summarises unfamiliar code; the mental model of the load-bearing pieces has to be yours, not AI's. You delegate the legwork — file summaries, pattern-finding across the codebase, draft documentation — and you hold the architectural and prioritisation judgment.

Your Role

You're the inheriting maintainer for a four-week engagement. Take ownership of what's running, fix the three known broken pieces, and produce the documentation that lets the next maintainer (or AI) work on the system without phoning you or Dilnoza. The platform itself is the deliverable that already exists. The handover packet is the deliverable that doesn't.

The register is supervisory at full expression. You design the inheritance plan, decide which fixes to ship and which to defer, and hold AI in restraint against its strongest "let's rewrite this" instinct. The AI infrastructure for this project isn't yours to design — Dilnoza's CLAUDE.md is part of what you inherit, and curating it is part of the assessment work.

What's New

Last time you built a multi-audience extension-program platform from paper for a provincial government office in Goroka, Papua New Guinea — greenfield, you set the architecture, every artifact shaped to its audience.

This project is the opposite kind of work.

There is no brief. Rustam's first message names symptoms and a deadline. The system itself is the only architectural artifact that exists. The architect work is the inheritance plan — what to investigate first, what to ask Dilnoza about while she's still available, what to write down before she leaves, what to fix during the engagement, what to defer with documentation that makes the deferral safe.

Discovery runs in parallel against two people on different timelines. Rustam holds the business priorities and the symptoms in non-technical language and stays available throughout. Dilnoza holds the technical context — the architecture-as-built, the silk-thread-colour encoding she invented, the URL structure the SEO depends on, the workarounds she put in for production constraints she never had time to fix. She leaves in four weeks. Questions to her are prioritised by what cannot be recovered from the code after she's gone. You are the most senior technical person on the workshop's payroll the moment she walks out — nobody reviews your work or holds the codebase but you. One outside voice is reachable on demand in chat, an independent handover consultant who knows the discipline of inheriting someone else's production system but holds none of this codebase's context; he will redirect any code-specific question straight back to Dilnoza, because she built it and he didn't.

Verification at full expression now means verifying code you didn't write. Mutation testing as a diagnostic on Dilnoza's inherited tests. Coverage designed against the workshop's actual operational pressures — the catalog SEO must not break, the export documents must reach customs cleanly, the production tracking must keep working through the dyeing season — not against engineering convenience. Every fix ships against operational pressure on a system the workshop depends on daily.

Tools

• The Ipak Yoli platform stack as it currently exists — a Node.js + Express API, a server-rendered Pug frontend with Alpine.js progressive sprinkles, PostgreSQL on a single managed instance, single-VM deployment behind a basic CDN, a server-side PDF generator for export documents, and a custom silk-thread-colour encoding module. You inherit it; the materials zip ships it as a coherent, bootable platform.
• git log, git blame, git bisect — for archaeology against an unfamiliar repository.
• Stryker — continuing. Mutation testing as a diagnostic on the inherited test suite.
• Lighthouse, Lighthouse CI, WebPageTest — continuing. Catalog-search and mobile-page diagnostics; the regression-testing harness installed onto the catalog routes.
• EXPLAIN, slow-query logging — for the catalog-search diagnosis.
• The existing observability stack — Prometheus configured but no alerting, basic application logging, two stale Grafana dashboards. You assess it, supplement it where the maintenance work requires it, and document the deferred rebuild.
• Claude Code with the supervisory register — and the AI infrastructure inherited from Dilnoza, curated rather than designed. VS Code, Git, GitHub.

Materials

• The first-contact Slack message from Rustam in #project-ipak-yoli, naming what he knows: Dilnoza is leaving, the catalog search is slow, some pages don't display on mobile, the export documents sometimes generate with formatting errors and have caused customs delays.
• Dilnoza's running platform under inherited-platform/ — source code, seed database with realistic product/customer/order data, the silk-thread-colour encoding module she invented, her sparse Mocha test suite (with the gaps that explain the bugs Rustam reports), her thin observability config, three years of git history, and the customs-rejected document samples that reproduce the export bug.
• Dilnoza's stale inherited-platform/CLAUDE.md — contradictory entries from different stages of the system's life, implementation details mixed with architectural constraints, accurate constraints buried under stale ones. You curate it in Unit 1; the curated version becomes the AI directing infrastructure for the rest of the engagement.
• Dilnoza's inherited-platform/README.md to "whoever takes this over" — candid, slightly tired, naming what she built first vs added under deadline pressure, naming the catalog SEO as the thing she most worries about the next person disturbing.
• A short curated reference set under references/ — a maintenance-discovery checklist, a git-archaeology pattern reference, a "reading code AI did not write" reference, a triage-and-restraint reference, and the WCAG AA mobile checklist.
• Templates with section headers and TODO guidance for the engagement's deliverables — the assessment, the engagement plan, the inherited-decisions log (what Dilnoza decided and why, recovered from her testimony), the engagement-decisions log (what you decide about which fixes to ship and which to defer), the architecture-as-built (Dilnoza-reviewed), the test-suite triage, the observability assessment, the diagnostic path for the export-document bug, and the recovered threat model.

No brief, no system design, no architecture diagram, no documented test plan, no migration plan. The system is the brief. The architect work is the inheritance plan you write in Unit 1. The handover packet under docs/handover/ doesn't exist yet — it's what you produce in Unit 6 against everything you write across the engagement.