Covers June 10 - 28, 2026.
Until this month, aidd had an assumption baked in everywhere: every project it had ever seen was mine. Point it at a directory and it expected to find (or create) its own .aidd/ contract, its own conventions, its own gates. That left quite a bit to change before I could use it on someone else’s code. Most of June went into that work.
The design doc gave aidd two jobs: build new projects and ingest existing ones. Spernakit is the default target stack, but not the only destination. Adopting an existing project means aidd learns it and manages it - analyzes the code, infers a profile, generates a feature inventory, runs audits, writes an intake report. It does not rewrite anything. If a rewrite ever happens, that’s a separate decision made later and approved explicitly. The doc’s wording: “an audited, recipe-driven migration path with evidence, checkpoints, and validation.”
To enforce the restriction, metadata-only runs get a write allowlist of exactly ['.aidd']. The orchestrator snapshots the worktree before each step and mechanically reverts writes outside it.
The guard hole
I dogfooded the ingest lane on a real outside project the same day it was built. The first run found a hole in the guard within the hour.
The guard watched for uncommitted changes. The agent committed the forbidden file, so there was nothing left for it to find in the working tree. I hadn’t considered that path when I designed it.
The same run turned up a couple more gaps (legitimate output under a gitignored .aidd/ was being classified as “produced no result,” and the interview step crashed on a fresh ingest). That was three findings in an hour. I need to do more of these runs against projects I haven’t set up myself.
Templates
The second half of Intake was generalizing project creation. The old implementation was a hardcoded switch: fresh project or Spernakit. Now there’s a template registry. Any scaffold command can be registered, and a third-party template runs create-then-ingest: scaffold with someone else’s starter, then immediately ingest whatever came out. aidd doesn’t need to understand the T3 stack or Laravel; it examines their output like any other foreign codebase.
Spernakit is just another supported template to aidd now.
The git reset
On June 18, during routine verification, a dogfooded run did a git reset against my live working tree and threw away an in-flight commit.
I got it back with git merge --ff-only (the commit object was still recoverable), but I was rattled enough to write it down that night: an orchestrator with git powers needs the same isolation I’d been demanding of its coding agents. Worktree isolation landed the next day.
With worktree mode enabled, each coding run executes in its own per-run git worktree on branch aidd/run-<id>. A clean run merges back, fast-forward preferred, gated on a clean live tree. A failed run just gets discarded. A conflicting merge parks as waiting_approval with its own exit code. A side benefit I didn’t plan for: separate worktrees let multiple runs edit one project without sharing working files, though their changes can still conflict at merge. The same release added warn-only cost and token budgets (I want to watch the numbers a while before letting them kill runs) and a couple of smaller gates.
Two smaller June episodes stuck with me. Penelope’s Loom got deleted - an animated dashboard visualization that had won a four-way bake-off six days earlier, removed end to end anyway. And the benchmark harness learned real cost accounting: one backend’s cached tokens were being double-counted, quietly handing it composite scores it hadn’t earned. Fixing the accounting changed the ranking outright. The corrected leaderboard, generated the following week, and my favorite pricing anecdote so far are in Leave a Coding Agent Running Eight Hours Without Losing Work.
The blocker loop had its first real workout. Agents using the template faced three tough product decisions. There was real ambiguity, which a bot couldn’t guess. So, they filed written analyses and marked the features as waiting_approval. Two weeks later, my decisions came back and got implemented in a day.
One key issue was an attacker who could lock an account with a few bad guesses. Worse, this lockout would eject the victim from sessions they were already signed into. From three possible fixes, I chose the surgical one: a lock that blocks new sign-in attempts but keeps live sessions active.
The other two fixes involved a quality-gate rule for the template’s auth core and a bookkeeping standard for feature blueprints. They were less dramatic but followed the same pattern: write up the ambiguity and wait for a human.
As of today, most of the platform features from the design doc are live: three-lane intake, the registry, the write guard, worktree isolation, and intake reports. It is still used daily for testing.
I still haven’t decided what to do with the commercial plan. I wanted to prove the tools first, and I’ve spent months doing that. The sales and outreach part is looking less appealing every time I think about it.