# 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