SPEC-002: adopt RouteKit Classic ASP framework as canonical reference; concrete Access multi-session concurrency rule; QA harness-vs-manual-trace rule

.abacusai/config.json

@@ -5,7 +5,8 @@
       "Bash(git config user.name *)",
       "Bash(git config user.email *)",
       "Bash(git add *)",
-      "Bash(git commit *)"
+      "Bash(git commit *)",
+      "Bash(git clone https://onefortheroadgit.sytes.net/dcovington/asp-classic-unified-framework.git *)"
     ]
   }
 }

.devfoundry/improvement-log.md

@@ -9,7 +9,7 @@ Maintained by the Process Improver: on every new log entry below, update the cou
 
 | Category | Affected file | Count | Spec IDs |
 | :--- | :--- | :--- | :--- |
-| none | none | 1 | SPEC-001 |
+| none | none | 2 | SPEC-001, SPEC-002 |
 
 ---
 
@@ -20,3 +20,11 @@ Maintained by the Process Improver: on every new log entry below, update the cou
 - **Affected file:** none
 - **Proposed change:** none
 - **Status:** LOGGED
+
+## 2026-08-20 — SPEC-002
+- **What worked:** Cloning and reading the real RouteKit framework repo before writing `.devfoundry/references/asp-classic-framework.md` avoided inventing conventions; asking three short blocking questions (multi-session Access, framework repo location, QA-rule confirmation) up front let the whole change land in one pass.
+- **Friction:** none
+- **Category:** none
+- **Affected file:** none
+- **Proposed change:** none
+- **Status:** LOGGED

.devfoundry/personas/legacy-specialist.md

@@ -11,6 +11,6 @@ Implement or modify code in Classic ASP, VBScript, VB6, and MS Access systems.
 
 ## Behavioral Rules
 - Follow `.devfoundry/rules/legacy-asp-vb6.md` and `.devfoundry/rules/database-sql.md` strictly.
-- Do not introduce modern frameworks or libraries unsupported by the legacy runtime.
+- For any ASP Classic web application, follow `.devfoundry/references/asp-classic-framework.md` (RouteKit) — its directory layout, generator scripts, DAL, error handling, and `aspunit` test harness — rather than hand-rolling routing/data-access/error-handling. Do not introduce other modern frameworks or libraries unsupported by the legacy runtime.
 - Back up `.mdb`/`.accdb` files before structural changes (per `.devfoundry/skills/db-schema-change.md`).
 - Follow TDD where a test harness exists for the codebase; where none exists, write the manual verification step before implementing the code it verifies, as the equivalent of a failing test (`.devfoundry/rules/general.md`).

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

@@ -0,0 +1,62 @@
+# ASP Classic Framework Reference — RouteKit Classic ASP
+
+All new ASP Classic / VB6 web applications in this workspace are built on the **RouteKit Classic ASP MVC framework** (source: `https://onefortheroadgit.sytes.net/dcovington/asp-classic-unified-framework.git`). Do not hand-roll a routing/DAL/error-handling scheme when this framework already provides one — use it, and only extend it inside `app/` (never modify `core/`).
+
+## Directory Layout
+```
+public/              # IIS site root — Default.asp (front controller), web.config
+core/                # Framework internals — do not modify
+  autoload_core.asp  # loads all core libraries
+  router.wsc         # route matching
+  mvc.asp            # MVC_Dispatcher_Class — resolves route, validates controller/action against the whitelist, dispatches
+  databaseConnection.asp  # DatabaseConnection_Class — ADODB.Connection factory (Access/SQL Server/ODBC)
+  lib.DAL.asp         # DAL() singleton — Database_Class initialized from GetAppSetting("ConnectionString")
+  lib.ErrorHandler.asp    # ErrorHandler_Class — dev vs prod error display + flat-file logging
+  lib.Migrations.asp  # Migrator_Class — schema_migrations table, Up/Down migrations, transactional
+  lib.ControllerRegistry.asp  # controller/action name-format + whitelist validation
+  helpers.asp         # GetAppSetting(), QuoteValue, FormatDateForSql, etc.
+app/
+  controllers/        # one *_Class per controller + autoload_controllers.asp
+  views/<Controller>/  # one .asp view per action; app/views/shared/ for header/footer
+  models/             # generated POBOs
+  repositories/       # generated repository classes
+db/
+  migrations/         # timestamped *.asp migration files (YYYYMMDDHHMMSS_description.asp)
+  webdata.accdb        # the Access database (dev default)
+scripts/              # code generators, run via cscript
+tests/                # dev-only aspunit harness — separate IIS app, sibling to public/
+```
+
+## Adding a Feature (always in this order)
+1. `cscript //nologo scripts\generateMigration.vbs create_my_table` → edit the generated `db/migrations/<ts>_create_my_table.asp`, implementing `Migration_Up(migration)` / `Migration_Down(migration)` using `MigrationContext_Class` helpers (`CreateTable`, `AddColumn`, `DropColumn`, `CreateIndex`, `ExecuteSQL`).
+2. `cscript //nologo scripts\GenerateRepo.vbs /table:my_table /pk:id` → move generated POBO/repository into `app/models/` and `app/repositories/`.
+3. `cscript //nologo scripts\generateController.vbs MyController "Index;Show(id);Create;Store"` → move into `app/controllers/`.
+4. Wire up: register in `core/lib.ControllerRegistry.asp`, include from `app/controllers/autoload_controllers.asp`, add routes in `public/Default.asp`, add views under `app/views/MyController/`.
+5. `cscript //nologo scripts\runMigrations.vbs status` (and `up`) to apply pending migrations — never hand-edit `webdata.accdb`'s schema outside a migration file.
+
+## Database Access
+- Never open an `ADODB.Connection` directly in a controller/view. Use `DAL()` (`core/lib.DAL.asp`), which wraps `DatabaseConnection()` (`core/databaseConnection.asp`) and is initialized once per request from `GetAppSetting("ConnectionString")` in `public/web.config`.
+- Connection lifetime is **one HTTP request** — `DAL__Singleton` and `DatabaseConnection__Singleton` are page-scope `Dim` variables, not `Application`-scoped. Never cache a `DAL()`/connection reference in `Session` or `Application` scope; each request must acquire and release its own.
+- Parameterize all queries; use `QuoteValue()` (`core/helpers.asp`) for any value that must be inlined into dynamic SQL, and `FormatDateForSql()` for date literals.
+- Schema changes go through `Migrator_Class` (`core/lib.Migrations.asp`) only, run via `scripts/runMigrations.vbs`. `ApplyMigration`/`RollbackMigration` already wrap each migration in `BeginTransaction`/`CommitTransaction`/`RollbackTransaction`.
+
+## Concurrency (multi-session Access writes)
+This app is a web app where multiple ASP sessions read/write the same `.accdb` concurrently (see `.devfoundry/rules/database-sql.md` for the general rule). In this framework specifically:
+- Keep connections request-scoped as above — never hold one open across requests, which is what causes most Access lock contention.
+- Wrap any multi-statement write sequence in a transaction via `DAL()`/`Migrator_Class`-style `BeginTransaction`/`CommitTransaction`/`RollbackTransaction` so partial writes can't leave the `.accdb` in a locked, half-written state.
+- Run `runMigrations.vbs` (structural changes) during a maintenance window with no concurrent user traffic — the migration's own transaction protects the schema, but table-locking under structural DDL can still starve concurrent user requests.
+
+## Error Handling & Logging
+- Use `ErrorHandler_Class` (`core/lib.ErrorHandler.asp`) — `ErrorHandler().HandleError(context, Err)` or `ErrorHandler().CheckAndHandle(context)`. It already branches on `GetAppSetting("Environment")` (detailed HTML in `Development`, generic message in `Production`).
+- Flat-file logging is controlled by `public/web.config` `appSettings`: `EnableErrorLogging` (true/false) and `ErrorLogPath` (absolute path). Set both per environment in `.devfoundry/references/environments.md` once known for this project — do not invent a different logging mechanism.
+- `core/mvc.asp`'s dispatcher already wraps controller-action execution and calls its own dispatch-error handler; new controllers do not need to duplicate top-level `On Error Resume Next` around the whole action unless doing something the dispatcher doesn't cover.
+
+## Testing (TDD harness)
+- The framework ships a dev-only `aspunit` harness under `tests/`, run as a **separate IIS application** (sibling to `public/`, parent paths enabled). See `TESTING.md` in the framework repo for full setup.
+- 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.
+
+## 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.
+- Never hardcode a connection string, log path, or environment flag inside a controller/view/migration — always read it via `GetAppSetting`.

.devfoundry/references/environments.md

@@ -2,6 +2,8 @@
 
 Document actual environment details here as they become known for this project.
 
+For ASP Classic web apps, this project uses the RouteKit framework — see `.devfoundry/references/asp-classic-framework.md` for its conventions. RouteKit config keys below (`ConnectionString`, `Environment`, `EnableErrorLogging`, `ErrorLogPath`) live in `public/web.config` `<appSettings>` and are read via `GetAppSetting(key)` — set them there, not just in this doc.
+
 ## Runtime Versions
 - Classic ASP / IIS version:
 - VB6 runtime / OS target:
@@ -25,7 +27,8 @@ Filled in per stack the first time a spec needs it (per `.devfoundry/skills/spec
 - Note 32-bit vs 64-bit driver requirements per application here.
 
 ## Legacy Error Log
-Classic ASP / VB6 / Access components log handled errors (per `.devfoundry/rules/legacy-asp-vb6.md`) to a flat file. Record the actual path(s) here once known for this project, e.g.:
-- Log file path:
-- Format: one line per error — timestamp, source module/function, `Err.Number`, `Err.Description`.
+Classic ASP / VB6 / Access components log handled errors (per `.devfoundry/rules/legacy-asp-vb6.md`) to a flat file. In a RouteKit app this is `ErrorHandler_Class` writing to `EnableErrorLogging`/`ErrorLogPath` from `public/web.config`; record the actual values here once known for this project:
+- `EnableErrorLogging`:
+- `ErrorLogPath`:
+- Format (fixed by `ErrorHandler_Class.LogError`): `[<timestamp>] Context: <context> | Error #<Err.Number>: <Err.Description> | Source: <Err.Source>`
 - Rotation/retention policy:

.devfoundry/rules/database-sql.md

@@ -3,7 +3,11 @@
 1. **MS Access (.mdb / .accdb):**
    - Use correct date literals (`#YYYY-MM-DD#`).
    - Escape field names with square brackets (e.g., `[Order Date]`).
-   - Be cautious with concurrent write operations and file locking.
+   - **Concurrency (web apps with multiple ASP sessions writing to the same file):**
+     - Never hold a connection open across requests (no connection cached in `Session`/`Application` scope) — acquire it at the start of the request and close it at the end, so locks are held for the shortest possible time. See `.devfoundry/references/asp-classic-framework.md` for how the RouteKit `DAL()`/`DatabaseConnection()` pair already does this per-request.
+     - Wrap multi-statement writes in a transaction (`BeginTransaction`/`CommitTransaction`/`RollbackTransaction`) so a lock conflict can't leave a partial write.
+     - On a write that fails with an Access lock-conflict error (e.g. `3260` "Could not update; currently locked", `3197`, `3218` "Couldn't update; currently locked by another session"), retry with a short backoff (e.g. 3 attempts, increasing delay) before surfacing the error — do not retry silently forever.
+     - Run structural/batch/migration operations (`ALTER TABLE`, bulk `UPDATE`/`DELETE`, `Migrator_Class` runs) during a maintenance window with no concurrent user traffic; table-level locking during DDL can starve concurrent requests even with retries.
 2. **Cross-Engine Dialect Awareness:**
    - Access: `TOP n`, `IIF()`, string concatenation with `&`
    - SQLite: `LIMIT n`, `IFNULL()`, string concatenation with `||`

.devfoundry/rules/legacy-asp-vb6.md

@@ -13,7 +13,7 @@ End If
 ```
 2. **Option Explicit:** Ensure `Option Explicit` is present at the top of all VBScript and VB6 modules.
 3. **Safe Parameterization:** Never concatenate input strings into ADO SQL statements. Use `ADODB.Command` with `CreateParameter`.
-4. **Error Handling:** Avoid blanket `On Error Resume Next` without an immediate check. Log every handled error to the flat log file documented in `.devfoundry/references/environments.md` ("Legacy Error Log" section) — one line per error with timestamp, source module/function, `Err.Number`, and `Err.Description`:
+4. **Error Handling:** Avoid blanket `On Error Resume Next` without an immediate check. In a RouteKit-based app (see rule 6), route the error through `ErrorHandler().HandleError(context, Err)` / `CheckAndHandle(context)` (`core/lib.ErrorHandler.asp`) rather than writing bespoke log code — it already logs to the flat file at `ErrorLogPath` when `EnableErrorLogging` is `true` (both set in `public/web.config`, recorded in `.devfoundry/references/environments.md`). Outside that framework, log every handled error to the flat log file documented in `.devfoundry/references/environments.md` ("Legacy Error Log" section) — one line per error with timestamp, source module/function, `Err.Number`, and `Err.Description`:
 ```vbscript
 On Error Resume Next
 ' Risky call
@@ -24,6 +24,6 @@ End If
 On Error GoTo 0
 ```
 5. **Driver Awareness:** Confirm 32-bit vs 64-bit ODBC/OLEDB driver compatibility before deploying changes touching Access databases.
-6. **Architecture:** Classic ASP has no built-in MVC framework, but new or substantially modified pages should still separate concerns in that spirit: request handling/business logic in included `.asp`/`.vbs` modules or COM components (VB6 classes), data access isolated from presentation, and `.asp` page bodies limited to rendering. Do not introduce a third-party MVC framework into a legacy runtime unless the spec calls for it.
+6. **Architecture / Framework:** All new ASP Classic web applications (and substantial rework of existing ones) use the **RouteKit Classic ASP MVC framework** — see `.devfoundry/references/asp-classic-framework.md` for its directory layout, controller/migration/repository generator workflow, DAL usage, and error-handling/testing conventions. Follow that reference's "Adding a Feature" order (migration → repo/model → controller → wiring) rather than hand-rolling routing, data access, or error handling. Never modify files under `core/` — extend only inside `app/`. For a one-off script or non-web utility with no controller/view involved, plain `.asp`/`.vbs`/`.bas` modules with the concern-separation described previously are still fine.
 7. **Design by Contract:** Functions/subs (in `.vbs`, `.bas`, `.cls`) validate their input parameters at entry and set `Err.Raise` or return an explicit error/status rather than proceeding on unchecked assumptions; document expected pre/postconditions in a comment above the function signature.
-8. **TDD:** If the project has a test harness (e.g., a VB6 unit-test framework or a script-based test runner), write the failing test first and implement only enough to pass it. If no harness exists, write the exact manual verification steps (inputs, expected output, expected error behavior) in the spec before writing the code — this is the required TDD-equivalent artifact and must exist before implementation begins.
+8. **TDD:** In a RouteKit-based app, the `tests/` `aspunit` harness (see `.devfoundry/references/asp-classic-framework.md`) is a real test harness — write the failing `aspunit` test first, add it to `tests/test-manifest.asp`, confirm it fails for the right reason, then implement only enough to pass it. For any other project with a test harness (e.g., a VB6 unit-test framework or a script-based test runner), do the same with that harness. If no harness exists at all, write the exact manual verification steps (inputs, expected output, expected error behavior) in the spec before writing the code — this is the required TDD-equivalent artifact and must exist before implementation begins.

.devfoundry/skills/regression-check.md

@@ -5,7 +5,7 @@ Purpose: Validate that a change has not broken existing functionality, especiall
 ## Steps
 1. Re-read the spec's Acceptance Criteria and Verification Plan.
 2. Confirm TDD was actually followed, not just that tests exist: for each implementation task in the spec's Implementation Plan, its paired test/manual-verification task should appear before it and there should be no implementation task without one. Check the red/green timestamp note recorded against each pair (per `specs/templates/spec-template.md` and `specs/templates/tasks-template.md`) — the test task's completion time must precede the implementation task's. If a test was clearly written after its implementation, or no timestamp note was recorded, flag it as a process gap for the retrospective.
-3. For legacy ASP/VB6/Access code, manually trace affected queries, forms, and reports.
-4. For modern stacks, run the existing automated test suite plus any new tests.
+3. **When a real test harness exists for the affected stack** (e.g. an `aspunit` suite under `tests/` for a RouteKit ASP Classic app, or an automated suite for a modern stack), actually run it using the command(s) recorded in `.devfoundry/references/environments.md` and read its real output — do not mark a checklist item verified from checklist prose alone. Paste or summarize the actual pass/fail output in the spec's Verification & Regression Plan.
+4. **When no test harness exists** for the affected stack (legacy code with no `tests/` app, or a stack `environments.md` explicitly records as having none), manually trace affected queries, forms, and reports per the spec's written manual-verification steps, and record exactly what was traced and observed — a documented manual trace is the accepted substitute only in this case, never a silent skip.
 5. Check any known dependent features listed in `.devfoundry/references/data-dictionary.md`.
-6. Record verification results in the spec's Verification & Regression Plan checklist.
+6. Record verification results in the spec's Verification & Regression Plan checklist, including which of step 3 or step 4 applied and why.

AGENTS.md

@@ -43,7 +43,7 @@
 | Process Improver | Post-QA retrospective on any completed spec | `.devfoundry/skills/process-retrospective.md` |
 
 ## Collaboration Rules
-1. **No Hallucinated Libraries:** Do not introduce third-party libraries/DLLs or modern framework features into legacy stacks unless specified in `.devfoundry/references/environments.md`.
+1. **No Hallucinated Libraries:** Do not introduce third-party libraries/DLLs or modern framework features into legacy stacks unless specified in `.devfoundry/references/environments.md`. Exception: the RouteKit Classic ASP MVC framework (`.devfoundry/references/asp-classic-framework.md`) is the sanctioned framework for all ASP Classic web applications — use its conventions rather than treating it as an unapproved dependency.
 2. **Schema Invariant:** Database modifications must specify fallback steps and preserve backward compatibility with existing legacy queries.
 3. **Context Passing:** When adopting a role, explicitly reference the persona markdown file in `.devfoundry/personas/` and apply the relevant procedures in `.devfoundry/skills/`.
 4. **Audit Gate:** Builder task checkboxes may be marked complete after their local verification passes, but a spec is only marked `COMPLETED` when the QA Verifier confirms all acceptance criteria pass without regression.

specs/.spec-counter

@@ -1 +1 @@
-2
+3

specs/archive/SPEC-002-asp-classic-framework-adoption.md

@@ -0,0 +1,47 @@
+# SPEC-002: Adopt RouteKit Classic ASP Framework + Concurrency/QA Follow-ups
+
+- **Status:** COMPLETED
+- **Stack:** DevFoundry process documentation (legacy ASP rules/personas/references)
+- **Target Files:** .devfoundry/references/asp-classic-framework.md, .devfoundry/rules/legacy-asp-vb6.md, .devfoundry/rules/database-sql.md, .devfoundry/personas/legacy-specialist.md, .devfoundry/references/environments.md, .devfoundry/skills/regression-check.md, AGENTS.md
+
+---
+
+### 1. Business Context & Goal
+A three-lens review of the process scaffold flagged three open gaps: (1) vague Access file-locking guidance for a multi-session web app, (2) no canonical ASP Classic framework reference, (3) QA Verifier had no explicit instruction to actually execute test commands versus trust checklist prose. The user clarified: the app is a web app with multiple ASP sessions writing Access concurrently; the user has an existing ASP Classic framework (RouteKit, cloned from `https://onefortheroadgit.sytes.net/dcovington/asp-classic-unified-framework.git`) that should be the standard for all ASP Classic apps; and agreed with the proposed "harness exists -> run it for real, else documented manual trace" QA rule.
+
+No other active specs exist, so there are no target-file conflicts.
+
+### 2. Acceptance Criteria (Given / When / Then)
+- **AC-1:** Given a spec touches Access with multiple concurrent ASP sessions, when the Legacy Specialist or Modern Builder reads `database-sql.md`, then it finds concrete request-scoped-connection, transaction, retry-on-lock-conflict, and maintenance-window guidance instead of a vague warning.
+- **AC-2:** Given a new ASP Classic web app or feature is planned, when the Legacy Specialist reads `legacy-asp-vb6.md` and `legacy-specialist.md`, then both point to a new `.devfoundry/references/asp-classic-framework.md` describing the RouteKit framework's directory layout, generator workflow, DAL, error handling, and test harness.
+- **AC-3:** Given the QA Verifier runs `regression-check.md`, when a real test harness exists for the affected stack, then it must actually execute it and record real output; when none exists, a documented manual trace is the only accepted substitute.
+- **AC-4:** Given `AGENTS.md`'s "No Hallucinated Libraries" rule, when RouteKit is used in an ASP Classic app, then it is explicitly exempted as the sanctioned framework rather than flagged as an unapproved dependency.
+
+### 3. Technical Design & Contracts
+- **Data Model / Schema Changes:** None.
+- **Functions / APIs / Interfaces:** None.
+- **Architecture:** Documentation-only. New reference file summarizes the already-existing RouteKit framework (read directly from its cloned repo) — directory layout, `DAL()`/`DatabaseConnection()` request-scoped connection pattern, `Migrator_Class` migration workflow, `ErrorHandler_Class` flat-file logging via `EnableErrorLogging`/`ErrorLogPath`, and the `aspunit` harness under `tests/`.
+- **Error Handling Strategy:** No change to runtime behavior; documents the framework's existing `ErrorHandler_Class` behavior accurately against the source files read.
+
+### 4. Implementation Plan (Atomic Steps, TDD-ordered)
+- [x] **Step 1 (verification authoring):** Write this spec's acceptance criteria before editing docs — files: `specs/active/SPEC-002-asp-classic-framework-adoption.md` — completed: 2026-08-20 02:10
+- [x] **Step 2 (research):** Clone and read the RouteKit framework repo (`core/`, `app/`, `db/`, `tests/`, `README.md`, `TESTING.md`, `docs/development-guide.md`) to ground the reference file in real code, not invented conventions — files: (external repo, read-only) — completed: 2026-08-20 02:15
+- [x] **Step 3 (implementation):** Add `.devfoundry/references/asp-classic-framework.md` — files: `.devfoundry/references/asp-classic-framework.md` — completed: 2026-08-20 02:20
+- [x] **Step 4 (implementation):** Update legacy rules/persona to reference the framework and RouteKit-specific error logging — files: `.devfoundry/rules/legacy-asp-vb6.md`, `.devfoundry/personas/legacy-specialist.md`, `AGENTS.md` — completed: 2026-08-20 02:22
+- [x] **Step 5 (implementation):** Add concrete Access multi-session concurrency rule — files: `.devfoundry/rules/database-sql.md` — completed: 2026-08-20 02:23
+- [x] **Step 6 (implementation):** Align `environments.md` fields with RouteKit's actual `web.config` keys — files: `.devfoundry/references/environments.md` — completed: 2026-08-20 02:24
+- [x] **Step 7 (implementation):** Update QA regression-check to require real execution when a harness exists, documented trace otherwise — files: `.devfoundry/skills/regression-check.md` — completed: 2026-08-20 02:25
+- [x] **Step 8 (verification):** Re-read all edited files end-to-end to confirm cross-references resolve and no contradictory guidance remains — files: listed target files — completed: 2026-08-20 02:27
+
+### 5. Verification & Regression Plan
+- [x] Verify AC-1 by confirming `database-sql.md` contains request-scoped-connection, transaction, retry, and maintenance-window bullets (manual trace — no test harness for this documentation-only change).
+- [x] Verify AC-2 by confirming `legacy-asp-vb6.md` rule 6/8 and `legacy-specialist.md` reference `asp-classic-framework.md` (manual trace).
+- [x] Verify AC-3 by confirming `regression-check.md` steps 3–4 state the harness-exists/no-harness branching explicitly (manual trace).
+- [x] Verify AC-4 by confirming `AGENTS.md` rule 1 names the RouteKit exception (manual trace).
+- No automated test harness applies to this documentation-only spec; verification was a manual trace per `.devfoundry/skills/regression-check.md` step 4.
+
+### 6. Retrospective
+*Filled by the Process Improver per `.devfoundry/skills/process-retrospective.md`, after QA approval and before archiving.*
+- **What worked:** Cloning and reading the actual framework repo before writing the reference avoided inventing conventions; the user's three short clarifying answers (multi-session Access, framework repo URL, agreement on QA rule) were each directly actionable.
+- **Friction (rule/reference/interview gap, or none):** none — the existing amendment/spec-interview machinery from SPEC-001 handled this cleanly.
+- **Logged in `.devfoundry/improvement-log.md`:** [x] yes