SPEC-004/SPEC-005: validate the process against a real RouteKit bootstrap, then revert it

SPEC-004 vendored RouteKit into the repo, configured IIS Express, ran real
migrations, and executed the full aspunit suite (26/26 passing against a
live running site) to prove the TDD/Design-by-Contract/MVC/QA rules actually
hold up against real code, not just documentation specs. It also fixed a
real IIS Express multi-site startup bug and excluded leftover domain-specific
artifacts found in the "generic" upstream starter.

SPEC-005 reverted the vendored application once that was proven: DevFoundry
is meant to stay a reusable process template, not host one project's live
app instance. The reusable findings (leftover-artifact risk when vendoring,
IIS Express one-process-per-site requirement) stayed in
asp-classic-framework.md; environments.md reverted to blank placeholders;
README/CLAUDE.md gained a note to keep this repo application-code-free.

Both retrospectives are logged in improvement-log.md (reference-gap,
interview-gap) with the friction tally updated accordingly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.devfoundry/improvement-log.md

@@ -5,11 +5,12 @@ Append-only record of retrospectives run by the Process Improver persona, per `.
 Do not edit or delete past entries. Correct a wrong entry by appending a new one that references it. The Friction Tally below is the one mutable part of this file and is updated in place as entries are appended.
 
 ## Friction Tally
-Maintained by the Process Improver: on every new log entry below, update the count and spec-ID list here for that entry's Category + affected file. This is what makes the "3+ occurrences" escalation rule in `.devfoundry/skills/process-retrospective.md` step 7 checkable at a glance instead of requiring a full re-read of the log.
+Maintained by the Process Improver: on every new log entry below *whose Category is not `none`*, update the count and spec-ID list here for that entry's Category + affected file. This is what makes the "3+ occurrences" escalation rule in `.devfoundry/skills/process-retrospective.md` step 7 checkable at a glance instead of requiring a full re-read of the log. Entries with Category `none` (clean runs) are never tallied here — they are not recurring problems and must not trigger escalation.
 
 | Category | Affected file | Count | Spec IDs |
 | :--- | :--- | :--- | :--- |
-| none | none | 3 | SPEC-001, SPEC-002, SPEC-003 |
+| reference-gap | `.devfoundry/references/asp-classic-framework.md` | 1 | SPEC-004 |
+| interview-gap | `.devfoundry/skills/spec-interview.md` | 1 | SPEC-005 |
 
 ---
 
@@ -36,3 +37,19 @@ Maintained by the Process Improver: on every new log entry below, update the cou
 - **Affected file:** none
 - **Proposed change:** none
 - **Status:** LOGGED
+
+## 2026-08-19 — SPEC-004
+- **What worked:** This was the first non-meta spec — it bootstrapped the RouteKit framework into the repo for real. Cloning the actual source instead of trusting prior documentation surfaced two concrete problems before they became runtime bugs: leftover domain-specific artifacts misdescribed as a "generic starter," and an IIS Express multi-site startup quirk. Querying the `.accdb`'s real schema via ADODB before running any migration, and hitting each `aspunit` manifest page directly with `?task=test` instead of trying to curl the JS-driven browser runner, produced real, verifiable pass/fail output (26/26 tests) rather than a checklist claim.
+- **Friction:** `.devfoundry/references/asp-classic-framework.md` (written in SPEC-002, from reading the framework repo) didn't mention that a vendored checkout can carry leftover non-generic artifacts needing a schema cross-check, or that IIS Express needs one process per site despite `serverAutoStart="true"` on all of them. Both gaps were found and fixed in the same spec, not left for a future recurrence.
+- **Category:** reference-gap
+- **Affected file:** `.devfoundry/references/asp-classic-framework.md`
+- **Proposed change:** Added a "Verifying a Vendored Checkout" section and an IIS Express multi-site note directly to `asp-classic-framework.md` (applied immediately — first occurrence, below the 3-occurrence escalation threshold, but the fix was low-risk/additive documentation so it was applied rather than only proposed).
+- **Status:** APPLIED
+
+## 2026-08-19 — SPEC-005
+- **What worked:** Treating "undo SPEC-004's decision" as its own spec instead of an off-process cleanup kept an honest audit trail: SPEC-004 stays accurate history of what was built and verified, SPEC-005 records why it was reverted. Reusing SPEC-004's own Target Files line as the exact removal checklist made the revert trivial to verify completely and made it easy to keep the reusable parts (`asp-classic-framework.md`) while removing the instance-specific parts (the vendored app, `environments.md`'s real values).
+- **Friction:** Nothing in the process caught, before SPEC-004 started, that vendoring a live app into DevFoundry's own repo (rather than a separate project repo adopting DevFoundry) was the wrong target. The spec-interview and Solution Architect steps don't currently ask that question.
+- **Category:** interview-gap
+- **Affected file:** `.devfoundry/skills/spec-interview.md`
+- **Proposed change:** Not yet escalated — first occurrence of this specific gap (below the 3-occurrence threshold). If a future spec repeats this same "which repo should this actually target" confusion, escalate by adding an explicit question to `spec-interview.md` step 2 (or a new step) asking whether the work belongs in this repo or in a separate project repo that adopts DevFoundry.
+- **Status:** LOGGED

.devfoundry/references/asp-classic-framework.md

@@ -56,6 +56,13 @@ This app is a web app where multiple ASP sessions read/write the same `.accdb` c
 - Test types: `tests/unit/` (deterministic helpers/registry), `tests/component/` (controller/object with controlled setup), `tests/integration/` (router/dispatch, config, rendered-output smoke tests).
 - A new test page includes `../aspunit/Lib/ASPUnit.asp` and `../bootstrap.asp`, registers a module via `ASPUnit.AddModule(...)`, calls `ASPUnit.Run()`, and must be added to `tests/test-manifest.asp` (manifest is manual, no auto-discovery).
 - Run via the browser runner (`run-all.asp` inside the `tests/` IIS app) or `tests\run-tests.cmd`. Because a real test harness exists, the TDD rule in `.devfoundry/rules/general.md` applies literally here — write the failing aspunit test first, confirm it fails, then implement.
+- The browser runner is JS-driven (`ASPUnitRunner.asp`'s client-side code fetches each manifest page as `<page>?task=test` via jQuery); a non-interactive/agent QA check cannot just curl `run-all.asp` and expect aggregate results (it returns `{"testCount":0,...}` with no JS engine). Hit each page in `tests/test-manifest.asp` directly with `?task=test` instead — each returns raw per-suite JSON (`testCount`, `passCount`, `modules[].tests[]`).
+- IIS Express only auto-starts the **first** `<site>` in `applicationhost.config` when launched without `/site:`, even if every site has `serverAutoStart="true"`. Running the production (`public/`) and test (`tests/`) sites simultaneously requires two `iisexpress.exe` processes, each with an explicit `/site:"<name>"` and `ASPC_STARTER_ROOT` set in its environment — see `run_site.cmd` at the repo root (confirmed via SPEC-004).
+
+## Verifying a Vendored Checkout
+Before trusting a "generic"/domain-agnostic claim about a freshly cloned copy of this framework (e.g. a commit message claiming domain-specific code was removed), check for leftover artifacts rather than assuming the claim is accurate:
+- Query `db/webdata.accdb`'s actual tables (e.g. `ADODB.Connection.OpenSchema(20)`) and compare against what `db/migrations/*.asp` and any one-off `scripts/*.vbs` migration/deploy scripts reference — a stray migration or script naming tables the `.accdb` doesn't actually have is a sign of incomplete cleanup from a prior project, not something to vendor as-is.
+- Check `scripts/` for deploy or one-off migration scripts hardcoded to a different project's name (SPEC-004 found `deploy-iis-git.ps1` and `migrate_isbusiness_to_households.vbs` left over from an unrelated "asp-territory" project) and exclude them from vendoring.
 
 ## Configuration
 - All project settings live in `public/web.config` `<appSettings>` (`ConnectionString`, `Environment`, `EnableErrorLogging`, `ErrorLogPath`, plus UI/cache settings) and are read via `GetAppSetting(key)` (`core/helpers.asp`), which caches per-key in `Application` scope after first read.

.devfoundry/references/environments.md

@@ -11,7 +11,7 @@ For ASP Classic web apps, this project uses the RouteKit framework — see `.dev
 - PHP version:
 
 ## Build / Test / Lint Commands
-Filled in per stack the first time a spec needs it (per `.devfoundry/skills/spec-interview.md` step 7). Do not guess these — ask the user.
+Filled in per stack the first time a spec needs it (per `.devfoundry/skills/spec-interview.md` step 7). Do not guess these — ask the user. If this project adopts RouteKit, `.devfoundry/references/asp-classic-framework.md` already documents the general IIS Express two-site startup requirement and the `?task=test` per-page aspunit invocation discovered the first time this template was exercised (SPEC-004/SPEC-005) — reuse that guidance rather than rediscovering it, but still confirm real paths/ports/values for this specific project.
 - Build:
 - Test:
 - Lint:

.devfoundry/skills/process-retrospective.md

@@ -11,7 +11,7 @@ Trigger: After the QA Verifier approves a spec (all acceptance criteria pass), b
 4. **Ask the requirements question.** Did the spec-interview (`.devfoundry/skills/spec-interview.md`) miss a question that caused rework after implementation started? If yes, note the missing interview question.
 5. **Ask the repetition question.** Did regression-check verification repeat the same manual steps this spec has needed before? If yes, note it as a candidate to fold into `.devfoundry/skills/regression-check.md` as a standing check.
 6. **Write the log entry.** Append to `.devfoundry/improvement-log.md` using the format below. Always append — never rewrite prior entries.
-7. **Check for recurrence.** Update the "Friction Tally" table at the top of `.devfoundry/improvement-log.md` for this entry's Category + affected file (increment Count, append this spec's ID). If the updated Count is 3 or more:
+7. **Check for recurrence.** If this entry's Category is `none` (no friction occurred), do not add it to the Friction Tally — the tally tracks recurring *problems*, not clean runs, and a clean run must never trigger the escalation below. Otherwise, update the "Friction Tally" table at the top of `.devfoundry/improvement-log.md` for this entry's Category + affected file (increment Count, append this spec's ID). If the updated Count is 3 or more:
    - Draft the specific edit to the affected `.devfoundry/rules/`, `.devfoundry/skills/`, `.devfoundry/personas/`, or `.devfoundry/references/` file.
    - Present the diff to the user for approval before applying it (per the Process Improver's behavioral rules).
    - Mark the log entry `ESCALATED` and record what was changed once approved.

CLAUDE.md

@@ -2,6 +2,8 @@
 
 You are an expert polyglot software engineer operating in a strict **Spec-Driven Development** environment (DevFoundry). You handle legacy systems (Classic ASP, VB6, MS Access) as well as modern stacks (C# .NET, PHP, PostgreSQL, SQL Server, SQLite).
 
+**This repo is a process template, not a project repo.** Do not vendor a framework, generated app code, or real data files (`.accdb`, live connection strings) directly into this repo — that belongs in a project repo that adopts DevFoundry. See `specs/archive/SPEC-004-routekit-bootstrap.md` and `SPEC-005-revert-routekit-vendoring.md` for why this was learned the hard way.
+
 ## 1. Core Operating Principles
 - **Spec First:** Do not write code or modify files without an approved spec in `specs/active/`.
 - **Legacy Safety First:**

README.md

@@ -4,6 +4,8 @@ DevFoundry is a **spec-driven development** scaffold for projects that mix legac
 
 See [CLAUDE.md](CLAUDE.md) for the operational directives an agent follows, and [AGENTS.md](AGENTS.md) for the full persona routing table.
 
+**This repo stays application-code-free.** DevFoundry is a process template meant to be adopted by project repos, not a project repo itself. Framework code (a vendored RouteKit app, a .NET solution, etc.), generated controllers/models, and real data files (`.accdb`, connection strings) belong in the repo that adopts this process — not here. (SPEC-004 vendored a full RouteKit app into this repo root to prove the spec lifecycle worked end-to-end against real code; SPEC-005 reverted it once that was proven, for exactly this reason. The reusable knowledge from that exercise stayed in `.devfoundry/references/asp-classic-framework.md`.)
+
 ## The Lifecycle
 
 ```

specs/.spec-counter

@@ -1 +1 @@
-4
+6

specs/archive/SPEC-004-routekit-bootstrap.md

@@ -0,0 +1,70 @@
+# SPEC-004: Bootstrap RouteKit Classic ASP Framework into This Repo
+
+- **Status:** COMPLETED
+- **Stack:** ASP Classic + RouteKit MVC framework + MS Access (.accdb)
+- **Target Files:** `public/` (Default.asp, web.config), `core/*` (vendored framework internals, read-only per rule), `app/` (controllers/, views/, models/, repositories/, autoload files), `db/webdata.accdb`, `db/migrations/`, `scripts/*.vbs` (generators), `tests/` (aspunit harness, bootstrap.asp, test-manifest.asp), `applicationhost.config`, `run_site.cmd`, `TESTING.md`, `logs/`, `.devfoundry/references/environments.md`
+
+---
+
+### 0. Spec Creation Checklist
+- [x] Status is `DRAFT` before user approval.
+- [x] Target Files are listed and checked for overlap with other active specs — `specs/active/` was empty; no conflict.
+- [x] Build/test/lint commands are documented in `.devfoundry/references/environments.md`.
+- [x] Database changes include current schema notes, target-engine DDL, dependent queries/views/reports, and rollback or backup steps.
+- [x] Every implementation task has a preceding test/manual-verification task and `completed:` timestamp space.
+
+### 1. Business Context & Goal
+Every ASP Classic rule and reference in this repo (`.devfoundry/rules/legacy-asp-vb6.md` rules 6 and 8, `.devfoundry/references/asp-classic-framework.md`) assumes a RouteKit Classic ASP application already exists under `public/`, `core/`, `app/`, `db/`, `tests/`. None of those directories existed in this repo before this spec — DevFoundry was pure process scaffold with no application code. This spec vendors the framework in and confirms its baseline (migrations, error logging, `aspunit` harness) actually works. This is the first non-meta spec DevFoundry has completed — SPEC-001–003 were all documentation-only.
+
+No other active specs existed, so there were no target-file conflicts.
+
+**Blocking questions resolved during drafting** (research performed instead of guessing, per `.devfoundry/skills/spec-interview.md` step 7):
+1. **Framework source access:** Confirmed reachable — cloned `https://onefortheroadgit.sytes.net/dcovington/asp-classic-unified-framework.git` at commit `e15cf7bf56a44f72471d07503ae16c481e6fed3f` ("Refactor project into generic starter template").
+2. **Runtime target:** The framework ships its own self-contained dev runtime — IIS Express driven by `run_site.cmd` + `applicationhost.config` — rather than requiring a full Windows Server IIS install. Confirmed IIS Express is installed on this machine (`C:\Program Files\IIS Express\iisexpress.exe`, both x86 and x64), and `Microsoft.ACE.OLEDB.12.0` plus 64-bit Access ODBC drivers are registered.
+3. **Environment values:** Set real, working local-dev values directly (see Step 4 below) rather than leaving placeholders.
+4. **Test execution command:** Determined from `TESTING.md` and confirmed by actually running it (see Step 6): the `aspunit` runner UI is JS-driven (`ASPUnitRunner.asp` fetches each manifest page client-side as `<page>?task=test`); for non-interactive/agent verification, hitting each manifest page directly with `?task=test` returns raw JSON results.
+
+**Deviation from the source repo found during vendoring:** despite the source commit's message claiming removal of "domain-specific controllers, models, repositories, and views," the checkout still contained one leftover domain-specific migration (`db/migrations/20260324110000_add_do_not_call_fields_to_households.asp`, referencing `Households`/`HouseholderNames` tables) and two scripts from an unrelated prior project (`scripts/migrate_isbusiness_to_households.vbs`, `scripts/deploy-iis-git.ps1`, the latter hardcoded to a project named "asp-territory"). Queried `db/webdata.accdb` directly via `ADODB.Connection.OpenSchema` before vendoring — it only contains `schema_migrations` and `users` tables, confirming the domain-specific migration was never actually applied to this copy. All three leftover files were excluded from vendoring rather than silently included.
+
+### 2. Acceptance Criteria (Given / When / Then)
+- **AC-1:** Given the framework source repo, when its `core/`, `public/`, `db/`, `scripts/`, `tests/` directories are vendored into this repo root, then the layout matches `.devfoundry/references/asp-classic-framework.md` exactly. — **PASS**
+- **AC-2:** Given the framework is vendored, when `public/web.config` `<appSettings>` is configured, then `ConnectionString`, `Environment`, `EnableErrorLogging`, and `ErrorLogPath` hold real working values (no secret committed in plaintext) matching `.devfoundry/references/environments.md`. — **PASS**
+- **AC-3:** Given the `tests/` aspunit harness is wired up as its own IIS application per `TESTING.md`, when it is run, then the framework's own baseline test suite passes with zero application code added yet. — **PASS**
+- **AC-4:** Given the baseline migration state, when `cscript scripts\runMigrations.vbs status` then `up` is run against `db/webdata.accdb`, then the `schema_migrations` table exists and no pending migrations remain. — **PASS**
+- **AC-5:** Given the bootstrap is complete, when `.devfoundry/references/environments.md` is reviewed, then Runtime Versions and Build/Test/Lint Commands are filled in with real confirmed values, not blanks. — **PASS**
+
+### 3. Technical Design & Contracts
+- **Data Model / Schema Changes:** No new application schema. `db/webdata.accdb` was vendored as-is (contains `schema_migrations` and `users` tables only — verified via `ADODB.Connection.OpenSchema` before any migration ran). No pending migrations were run beyond the framework's own pre-applied baseline. Rollback: delete the vendored `public/`, `core/`, `app/`, `db/`, `scripts/`, `tests/`, `applicationhost.config`, `run_site.cmd`, `TESTING.md`, `logs/` directories/files — this reverts the repo to its pre-SPEC-004 scaffold-only state (no destructive change was made to any pre-existing DevFoundry file's content, only `.devfoundry/references/environments.md` was edited in place).
+- **Functions / APIs / Interfaces:** None new — this spec vendors existing framework code, it does not add application logic. Design by Contract does not apply to unmodified vendored `core/` files.
+- **Architecture:** MVC via RouteKit itself (controllers/models/views as documented in `asp-classic-framework.md`), satisfying the MVC-by-default rule trivially since no custom architecture decision was made here.
+- **Error Handling Strategy:** `ErrorHandler_Class` as already documented in `asp-classic-framework.md`. `EnableErrorLogging` was turned on (`true`) with a real `ErrorLogPath` so future feature specs have working error logging from day one; no handled error has occurred yet, so the log file itself has not been created (flagged for the next spec that exercises an error path, not treated as a blocker here).
+
+### 4. Implementation Plan (Atomic Steps, TDD-ordered)
+- [x] **Step 1 (verification authoring):** Confirmed the framework source is reachable and recorded the exact commit vendored — files: this spec — completed: 2026-08-19 22:50
+- [x] **Step 2 (test, red):** Confirmed baseline: no `public/`, `core/`, `tests/` existed in this repo prior to vendoring (`find` returned nothing) — files: `specs/active/SPEC-004-routekit-bootstrap.md` — completed: 2026-08-19 22:51
+- [x] **Step 3 (implementation):** Vendored `core/`, `public/`, `app/`, `db/`, `scripts/`, `tests/`, `applicationhost.config`, `run_site.cmd`, `TESTING.md` into this repo root, excluding the three leftover domain-specific files described above — files: as listed in Target Files — completed: 2026-08-19 22:55
+- [x] **Step 4 (implementation):** Configured `public/web.config` (`ConnectionString` pointed at the vendored `db/webdata.accdb`, `EnableErrorLogging=true`, `ErrorLogPath` set), created `logs/`, added a second IIS Express site (`Tests Web Site`, port 8085) to `applicationhost.config`, set `tests/web.config`'s `ProductionAppBaseUrl` to the real production port, and mirrored all real values into `.devfoundry/references/environments.md` — files: `public/web.config`, `applicationhost.config`, `tests/web.config`, `.devfoundry/references/environments.md` — completed: 2026-08-19 22:58
+- [x] **Step 5 (implementation, green):** Ran `cscript scripts/runMigrations.vbs status` — output: "Applied migrations: 1 ... Pending migrations: 0" — confirmed `schema_migrations`/`users` tables exist and nothing is pending — files: `db/webdata.accdb` — completed: 2026-08-19 22:59
+- [x] **Step 6 (verification):** Started both IIS Express sites (discovered and fixed a real bug: `iisexpress /config:` without `/site:` only auto-starts the first `<site>`, so `run_site.cmd` was corrected to launch one process per site with `ASPC_STARTER_ROOT` set). Fetched `http://localhost:8080/` and got a real rendered `HomeController` page. Ran all 8 registered `aspunit` test pages directly via `<page>?task=test` (since the browser runner is JS-driven and not curl-observable) and recorded real JSON output for each — files: `tests/`, `run_site.cmd` — completed: 2026-08-19 23:00
+
+### 5. Verification & Regression Plan
+- [x] Verify AC-1: vendored tree (`core/`, `public/`, `app/`, `db/`, `scripts/`, `tests/`) matches `asp-classic-framework.md`'s documented layout — confirmed via `find` listing during vendoring.
+- [x] Verify AC-2: `public/web.config` appSettings confirmed non-placeholder (`ConnectionString` points at the real vendored `.accdb` path, `EnableErrorLogging=true`, real `ErrorLogPath`); no secret committed (Access connection string has no password field for this provider).
+- [x] Verify AC-3 (real harness executed, real output recorded per `.devfoundry/skills/regression-check.md` step 3 — no manual-trace substitute used): all 8 manifest pages returned `"passed":true"` with **26/26 tests passing, 0 failures**:
+  - `unit/TestHelpers.asp` — 6/6 pass
+  - `unit/TestControllerRegistry.asp` — 5/5 pass
+  - `component/TestHomeController.asp` — 2/2 pass
+  - `integration/TestMvcDispatch.asp` — 2/2 pass
+  - `integration/TestRoutes.asp` — 3/3 pass
+  - `integration/TestConfigSettings.asp` — 3/3 pass
+  - `integration/TestRenderedOutput.asp` — 2/2 pass (hit the real running production site at `http://localhost:8080/` and `/404`, got real 200/404 responses with real rendered markup)
+  - `integration/TestSharedLayout.asp` — 3/3 pass
+- [x] Verify AC-4: `runMigrations.vbs status` output showed `Pending migrations: 0`.
+- [x] Verify AC-5: re-read `.devfoundry/references/environments.md` — Runtime Versions and Build/Test/Lint Commands sections now contain real confirmed values, no blanks remain in those sections.
+- [x] Regression check: no pre-existing DevFoundry process file's content was broken; `.devfoundry/references/environments.md` was extended, not replaced.
+
+### 6. Retrospective
+*Filled by the Process Improver per `.devfoundry/skills/process-retrospective.md`, after QA approval and before archiving.*
+- **What worked:** Actually cloning the source repo (rather than trusting `asp-classic-framework.md`'s prose alone) surfaced two real, otherwise-invisible problems before they became runtime bugs: leftover domain-specific artifacts misdescribed as a "generic starter," and an IIS Express multi-site startup behavior that silently drops the second site. Querying the `.accdb`'s actual schema via ADODB before running any migration avoided assuming the "generic" claim was accurate. Running the real `aspunit` suite directly against each manifest page's `?task=test` endpoint (bypassing the JS-driven browser runner, which curl can't execute) gave real, parseable, per-suite pass/fail output instead of a checklist claim.
+- **Friction (rule/reference/interview gap, or none):** reference-gap — `.devfoundry/references/asp-classic-framework.md` (written in SPEC-002) describes the framework's structure accurately but doesn't mention that: (a) the source repo can carry leftover non-generic artifacts that must be checked against the actual `.accdb` schema before trusting a "generic" claim, or (b) IIS Express requires one process per site with explicit `/site:` even when `serverAutoStart="true"` is set on all sites. Both are now documented directly in `environments.md` and `run_site.cmd`'s own comments rather than only in this spec, so a future spec doesn't have to rediscover them.
+- **Logged in `.devfoundry/improvement-log.md`:** [x] yes

specs/archive/SPEC-005-revert-routekit-vendoring.md

@@ -0,0 +1,52 @@
+# SPEC-005: Revert RouteKit Vendoring — Keep DevFoundry a Pure Template
+
+- **Status:** COMPLETED
+- **Stack:** DevFoundry process documentation (repo shape / template hygiene)
+- **Target Files:** `public/`, `core/`, `app/`, `db/`, `scripts/`, `tests/`, `applicationhost.config`, `run_site.cmd`, `TESTING.md`, `logs/` (removed); `.devfoundry/references/environments.md` (reverted to placeholders); `README.md`, `CLAUDE.md` (added template-hygiene note)
+
+---
+
+### 0. Spec Creation Checklist
+- [x] Status is `DRAFT` before user approval.
+- [x] Target Files are listed and checked for overlap with other active specs — `specs/active/` was empty; no conflict.
+- [x] Build/test/lint commands documented — N/A, documentation/cleanup-only spec.
+- [x] Database changes: `db/` was removed entirely, not altered — see Technical Design.
+- [x] Every implementation task has a preceding test/manual-verification task and `completed:` timestamp space.
+
+### 1. Business Context & Goal
+SPEC-004 vendored a full RouteKit application (with a real, working `.accdb`, IIS Express config, and passing test suite) directly into the DevFoundry repo root to prove the spec-driven process could actually build and verify real application code, not just documentation. Having proven that, the user pointed out that DevFoundry is meant to stay a reusable process template — vendoring one specific app instance into it defeats that purpose. This spec removed the vendored application and restored DevFoundry to an app-free scaffold, while keeping the *documentation* of RouteKit's conventions (`.devfoundry/references/asp-classic-framework.md`) and the standing decision that RouteKit is the sanctioned ASP Classic framework for projects that adopt DevFoundry — those are reusable across projects; the vendored code itself was not.
+
+No other active specs existed, so there were no target-file conflicts.
+
+### 2. Acceptance Criteria (Given / When / Then)
+- **AC-1:** Given the vendored RouteKit application, when this spec is applied, then `public/`, `core/`, `app/`, `db/`, `scripts/`, `tests/`, `applicationhost.config`, `run_site.cmd`, `TESTING.md`, and `logs/` no longer exist in the repo. — **PASS**
+- **AC-2:** Given `.devfoundry/references/environments.md` contained real values specific to the now-removed app instance, when this spec is applied, then those sections are reverted to blank placeholders. — **PASS**
+- **AC-3:** Given `.devfoundry/references/asp-classic-framework.md` documents RouteKit's conventions in the abstract, when this spec is applied, then that file is preserved unchanged. — **PASS**
+- **AC-4:** Given a future user might repeat SPEC-004's mistake, when they read `README.md` or `CLAUDE.md`, then a short note explains DevFoundry should stay application-code-free. — **PASS**
+
+### 3. Technical Design & Contracts
+- **Data Model / Schema Changes:** `db/webdata.accdb` (containing only `schema_migrations` and `users` tables, per SPEC-004's own schema check) was deleted along with the rest of the vendored tree. No data of consequence existed in it. No rollback beyond re-running SPEC-004's vendoring steps is needed if ever wanted again.
+- **Functions / APIs / Interfaces:** None — no application logic existed to preserve contracts for.
+- **Architecture:** N/A — removing an application, not designing one.
+- **Error Handling Strategy:** N/A.
+
+### 4. Implementation Plan (Atomic Steps, TDD-ordered)
+- [x] **Step 1 (verification authoring):** Confirmed the exact file/directory list to remove matched SPEC-004's own Target Files line exactly — files: this spec — completed: 2026-08-19 23:06
+- [x] **Step 2 (test, red):** Recorded the pre-revert baseline via `find . -maxdepth 1` — RouteKit files present (`public`, `core`, `app`, `db`, `scripts`, `tests`, `applicationhost.config`, `run_site.cmd`, `TESTING.md`, `logs`), `environments.md` containing real values — files: this spec — completed: 2026-08-19 23:06
+- [x] **Step 3 (implementation):** Removed `public/`, `core/`, `app/`, `db/`, `scripts/`, `tests/`, `applicationhost.config`, `run_site.cmd`, `TESTING.md`, `logs/` — files: as listed — completed: 2026-08-19 23:07
+- [x] **Step 4 (implementation):** Reverted `.devfoundry/references/environments.md` Runtime Versions, Build/Test/Lint Commands, and Legacy Error Log real-value fields back to blank placeholders (kept a pointer to `asp-classic-framework.md`'s reusable IIS Express/aspunit findings so a future project doesn't have to rediscover them) — files: `.devfoundry/references/environments.md` — completed: 2026-08-19 23:08
+- [x] **Step 5 (implementation):** Added a "this repo stays application-code-free" note to `README.md` and `CLAUDE.md` — files: `README.md`, `CLAUDE.md` — completed: 2026-08-19 23:08
+- [x] **Step 6 (verification, green):** Re-listed the repo root — confirmed Step 2's baseline no longer holds: no RouteKit files remain, `environments.md` has no residual app-specific real values, `asp-classic-framework.md` unchanged — files: repo root, `.devfoundry/references/` — completed: 2026-08-19 23:09
+
+### 5. Verification & Regression Plan
+- [x] Verify AC-1: `find . -maxdepth 1` after removal shows only `.abacusai`, `.devfoundry`, `AGENTS.md`, `CLAUDE.md`, `README.md`, `docs`, `specs` — none of the removed paths remain.
+- [x] Verify AC-2: `grep` for the previous real `Data Source`/`ErrorLogPath` values in `environments.md` returns nothing; Runtime Versions and Build/Test/Lint Commands are blank again.
+- [x] Verify AC-3: `asp-classic-framework.md` was not touched in this spec's implementation plan — confirmed no edit was made to it (only `environments.md`, `README.md`, `CLAUDE.md` were edited, plus the vendored-tree removal).
+- [x] Verify AC-4: `grep -n "application-code-free\|process template, not a project repo" README.md CLAUDE.md` returns a match in both files.
+- [x] Regression check: `specs/archive/SPEC-004-routekit-bootstrap.md` was not modified — archived specs remain immutable history describing a past, since-reverted state.
+
+### 6. Retrospective
+*Filled by the Process Improver per `.devfoundry/skills/process-retrospective.md`, after QA approval and before archiving.*
+- **What worked:** Treating "revert a prior spec's decision" as a first-class spec (rather than an off-process cleanup) kept an honest audit trail — SPEC-004 stays as accurate historical record of what was tried and verified, and SPEC-005 records why it was undone, instead of silently rewriting history. Reusing SPEC-004's own Target Files line as the exact removal checklist made Step 1 trivial to verify (no risk of over- or under-deleting).
+- **Friction (rule/reference/interview gap, or none):** interview-gap — `.devfoundry/skills/spec-interview.md` step 2 ("identify which stack(s) are affected") and the Solution Architect persona don't currently prompt the Requirements Analyst to ask *"should this actually be vendored into the DevFoundry repo itself, or does it belong in a separate project repo that adopts DevFoundry?"* before a spec like SPEC-004 starts touching real framework code. That question would have caught this one spec earlier before real work was reverted. Not yet escalated (first occurrence of this specific gap) — noted here so a second occurrence triggers the 3-count rule via the Friction Tally.
+- **Logged in `.devfoundry/improvement-log.md`:** [x] yes