7.2KB

Originalformat Blame Verlauf

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

Status is DRAFT before user approval.
Target Files are listed and checked for overlap with other active specs — specs/active/ was empty; no conflict.
Build/test/lint commands documented — N/A, documentation/cleanup-only spec.
Database changes: db/ was removed entirely, not altered — see Technical Design.
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)

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
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
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
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
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
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

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.
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.
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).
Verify AC-4: grep -n "application-code-free\|process template, not a project repo" README.md CLAUDE.md returns a match in both files.
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: yes

7.2KB Originalformat Blame Verlauf