Enq
Useful answers, no asset. The intelligence lived in the prompt and evaporated with it.
The problem
Knowledge work that needed the same reasoning applied over and over, with no durable place to put the reasoning. Each session started cold.
What it is
A task manager built around one input line: capture, aliasing, typed tags, notes and state transitions are all commands typed into the same place rather than screens you navigate to. Smart actions and context processors read the entry graph and propose the next move, so the tool arrives at the work instead of waiting to be told about it.
What it proved
Prompting produces output, not leverage. Anything worth repeating has to be written down somewhere the model can be pointed at — which is the argument that produced the spec.
The failure was informative enough to redirect everything after it.
By the numbers
Under the hood
engine, command seam, sync
One library holds the product. The frontends are opinions about how to reach it.
Command interpreter
All user input goes through one execute call that returns one base result type. Adding a capability means adding a handler; the clients do not learn a new path.
Data model
Entries carry content, aliases, tags, notes and state flags. Tags are definitions with a name, a format and validation, applied to entries as values — typed, not free-text strings.
AI layer
Smart actions and context processors live in the engine rather than in a client, so every frontend inherits them and none of them can drift from the others.
Integrations
A remote integration manager owns OAuth and external services from the core, so an integration is added once rather than once per client.
Progressive web app
Vanilla HTML, CSS and JavaScript with a service worker and a manifest, split into config, auth, api, commands, local database, UI and app modules. No framework and no build step.
Backend
The ASP.NET Core project is the live server: OAuth start and token refresh, command input, the expanded board view, and entry transitions for archive, complete and delete.
Live updates
A SignalR hub pushes entry changes to connected clients instead of making them poll for work that usually has not happened.
Auth
An OAuth provider authenticates, the server issues a JWT, the client stores it and sends it as a bearer token. One flow, identical across every frontend.
Carried forward
Into Mistwright — the first build where specifications began outweighing prompts.
Mistwright
Part-spec'd, part-prompted — and the specifications quietly started doing more of the work.
The problem
A 4X strategy game is an unusually honest forcing function: roughly thirty interacting systems — world generation, territory and influence, combat, economy, missions, alliances, heroes and technology — that all have to agree with each other, and no tolerance for the ones that only hold up in a demo. The constraint was that it had to ship single-player first and still be cheap to move to a server-authoritative model, without rewriting the systems that consume the state.
What it is
A Unity client and a .NET server built against a shared entity model and a written specification corpus covering the entity model, combat, inventory and engagement. The rules themselves are pure static logic with no engine dependency, so they unit-test in milliseconds without loading a scene and double as the reference implementation the server is written against.
What it proved
Where the spec was written, the work was reproducible. Where it was prompted, it was not. The line between the two halves of this build is the whole thesis of the year that followed.
By the numbers
Under the hood
determinism, service seams, content as data
Three decisions carry the codebase: seams at the migration boundary, rules with no engine dependency, and content as data.
Seeded generation
Stateful entities are placed from a fast seeded stream derived per world chunk; purely visual scatter uses noise instead. Two strategies, chosen per entity type, with the reasoning recorded as a decision rather than remembered.
Stream offsets
Every consumer draws its offset from one central table, so two systems can never silently share a stream and correlate. Adding a system means allocating an offset in the open.
The same world twice
Deterministic generation is what lets a client and a server agree about a world that neither of them had to store.
The interfaces
Mobile state, influence and missions each reach the game through an interface with a local implementation and a service accessor. The swap point for server-authoritative play is the bootstrap — one file.
Engine-free rules
The mission and influence logic are static classes with no engine reference. They test without a scene, and they are precisely what the server implements.
Sparse state
Territory influence is a sparse map keyed by a packed tile coordinate and stored as fixed-point hundredths, so memory tracks what is actually claimed rather than the size of the world.
Registries
Trees, rocks, decoratives, mobiles, buildings and missions all load from data at boot through the same registry pattern. Adding content is a data change with no code path behind it.
Convention over wiring
Unit visuals resolve by identifier convention rather than a hand-maintained inspector list, which is what keeps forty-nine unit definitions from becoming forty-nine chances to mis-wire a reference.
Where the tests point
The suite covers random-number generation, the damage formula, influence accrual, unlock rules and mission logic — the places where a quiet mistake is both expensive and invisible.
Carried forward
Into Polaris — the first build with no prompt-only half.
Polaris
The first true spec-driven build. With the spec as source of truth, prompting became closer to compilation.
The problem
New product introduction ran across disconnected artifacts — ideation notes, engineering gates, feature trackers, adopter lists, program reviews — with no single place where a product's state was true.
What it is
An end-to-end platform spanning ideation, gated engineering execution, feature tracking, first-adopter rollout and lifecycle program management — one system carrying a product from signal to general availability.
How it was built
- 01The specification written first and ratified as the source of truth — behaviour, data model, gates, edge cases.
- 02Implementation generated against the spec rather than described in prose, making regeneration cheap and drift visible.
- 03Changes made to the spec, not the code, so the artifact and the intent never separated.
What it proved
Output became reproducible. The same spec produced the same system, which is the property that makes an AI-built artifact safe to run in production and safe to hand to someone else.
Seven gated stages, eleven roles, and every field, deck, meeting and human-readable label in the process live in 21 configuration files the engine reads at boot — so the second process, and the fourth revision of the first, cost a configuration edit rather than a release.
By the numbers
Under the hood
five data planes, one engine
Five things that are normally code are data here. That is the whole design.
Workflow
Stages, sub-statuses, transitions, gates, decisions and approver roles live in configuration; the state-machine engine reads it at boot. Adding a stage is a configuration edit rather than a release.
Permissions
A single resolver consumes a role-to-action matrix with declarative scopes — assigned function, delegated field, own idea. No authorisation logic scattered through controllers.
Fields
One definition file declares every field’s key, label, format, scope, and the stages and functions it applies to. The renderer is a thin dispatch table over that declaration.
Slide decks
Decks are declared as ordered template instances; a registry maps template keys to components. The user-supplied background fills the 16:9 canvas and layout inside the slide is the template’s responsibility.
Labels
No human-readable string is hardcoded anywhere. One dictionary holds the copy, and one hook is the only way a component reaches it — so rewording the process never means editing a component.
Functional documents
A library of standard-work and readiness-checklist templates, cloned per idea on first use. Items materialise as real work items, so the work breakdown treats them like any other task.
Team tiering
Stakeholders carry a tier — core, full or external — and that tier drives the dynamic meeting and notification audiences instead of hand-maintained distribution lists.
Red flags
A first-class entity, optionally bound to a work item, raised inline during a status update or straight from a row in the work breakdown. Risk is recorded where it is noticed.
Cadence engine
A recurrence implementation extended for multi-day weekday sets and multi-week intervals, which is what phase-aware status updates need: one rhythm during Initiation, another during Build, another during Readiness.
Snapshots
The business case and charter are frozen to dated PDFs on entry to Build, so what was agreed stays legible after the living documents move on.
Data at rest
Column-level encryption for sensitive comment bodies, plus disk-level encryption at the infrastructure layer. Two independent layers, deliberately — neither one is asked to be the whole answer.
Calendars
Free/busy lookup sits behind a provider interface, with a static implementation standing in until the directory scope is granted. A pending IT approval never blocks a release.
Tests
Backend coverage over the workflow engine, permission resolver, field validation and the Build-phase services; frontend coverage over the field renderer, decision panel, slide deck and comment thread.
Change discipline
A workflow-shape change updates the human-readable mirror, the hand-authored diagram and the specification together. A deployment-affecting change updates the deployment document or it does not ship.
Carried forward
Into GUIDE — the method extracted from this build and generalised into a framework.
GUIDE
The method extracted into a framework — which now governs its own ancestors.
The problem
A method that works for one builder on one system is a personal habit. To become an operating model it has to survive being handed to teams who did not invent it.
What it is
The organisation's standard Agile engineering process with AI agents as first-class participants — derived independently, then deployed across four engineering teams.
What it requires
- 01Automated testing strong enough that a machine-authored change can be trusted or rejected mechanically.
- 02Product documentation rich enough to be read as context rather than consulted as reference.
- 03Human and mechanical quality gates placed where authority actually needs to sit.
What it proved
The method transfers. Mistwright and Polaris — the builds it was derived from — now run under it, which is the strongest available evidence that the framework is a real abstraction and not a retelling of one project.
By the numbers
Under the hood
spine, surface, personas, gates
Two surfaces, one rule: the spine never changes per project, and the project never touches the spine.
The spine
Constitution, process router, stage playbooks, host adapter, the generic gate bank and the spec-format tooling. Copied verbatim into every project and never edited there — which is what makes an update a mechanical operation instead of a merge.
The project surface
One project-details file in seven indexed sections, plus a gate configuration carrying paths, the clause-ID pattern and the inline constitution and seam rules. Cited one section at a time, never bulk-loaded.
The host surface
The rules file the agent host actually loads: an agent-neutral carrier as the canonical copy, with per-host stubs that route to it. One file to maintain, three hosts served.
Load discipline
The constitution and the router are always in context; a stage body arrives only when that stage starts, and takes its shards with it. Context budget is treated as a real resource.
The premise
One mind writing spec, tests and code writes the same misreading into all three, and every check passes. For work where a misread is expensive, the jobs go to separately scoped agents that cannot see each other’s output.
Host tiers
How much real isolation a host can deliver is recorded at adoption and governs how the loop runs. A host with genuinely scoped sub-agents runs it as written; a weaker host runs a declared, degraded variant rather than pretending.
Enforcement
A pre-tool hook denies an engineer-persona agent any edit to a test path. The separation is not advice in a document — the host refuses the write.
Gate bank
Generic and project gates shipped as matched PowerShell and shell pairs behind one runner and one config template. Gates are run, never loaded — they cost nothing in context.
Installer
Vendors the spine, places the carriers you name, installs the session commands, seeds the gate config and writes a hashed manifest. Update refuses a dirty tree or a locally edited spine file and never deletes; doctor reports every file whose hash has drifted.
Session lifecycle
Wrap, stash and unstash ship as installed commands, so checkpointing a context is a first-class operation with a defined shape rather than a habit each person reinvents.
Carried forward
Into the agentic transformation — GUIDE is the process the agents execute.
Agentic transformation
Agents run the lifecycle from market signal to support callback. Humans hold the roadmap, ratify the specs, authorize the releases.
The problem
AI assistance inside a delivery lifecycle speeds up individual tasks and leaves the lifecycle intact. The question worth answering is whether the lifecycle itself can be executed by agents without giving up the commitments the business is held to.
What runs
Investigation, triage, specification drafting, tests, code, verification, packaging, deployment and documentation — executed by agents end to end on one line of the business.
Where humans hold
- 01The roadmap. What gets built and in what order stays a human judgement about the market.
- 02Specification ratification. An agent may draft the spec; a human accepts it as the contract.
- 03Release authorization. Nothing reaches a customer without a named person authorizing it.
What it proved
The lifecycle itself can be executed by agents. Investigation through deployment runs without a human in the loop, while the three commitments the business is actually held to — what gets built, what the specification says, and what reaches a customer — stay with named people.
What product managers across the organisation see is cycle time. A month to plan and a sprint to ship has become results in production the same week — sometimes the same day.
Running on a production business line under the same release authorization as every other. Not a pilot with an exit.
Carried forward
Into the legacy line — the harder case, and the one that generalises.
The legacy line
Greenfield demos are commonplace. AI carrying Day-2 work on a crufty system is the version that matters to anyone who owns one.
The problem
Every AI transformation story is told on a clean codebase. Real portfolios are mostly old systems with customers on them, and the honest question is whether the model holds when there is no green field to build on.
What was done
A long-lived production system with paying customers on it — no green field, no rewrite budget, and a release cadence that could not pause while the operating model was proven. The agents took the work where the risk was legible first: characterisation tests and documentation over behaviour that already existed, then investigation and triage, then change execution behind the same gates the new line runs. Roadmap, specification ratification and release authorization stayed human, exactly as they do everywhere else.
What it proved
The operating model does not depend on a clean start. It depends on tests, documentation and gates — all of which can be built into a system that already exists, in the order the risk demands.
And the system got quieter. Emergency fixes take less of the week, more of the behaviour is written down as standard documentation, and the engineers on it plan what matters instead of absorbing what broke. Customers, support agents and engineers feel the same change from three sides.
Why it matters
Because it is the case most organisations are actually in.