wsc-mvc/IMPLEMENTATION_PLAN.md

WSC-MVC — Agent Execution Plan

Use this as an ordered queue. A checkbox is complete ONLY with actual test evidence in docs/TEST-RESULTS.md.

M0 — Environment and feasibility

• Inventory Windows version, IIS/Classic ASP/URL Rewrite availability, app pool bitness/identity, WSC registration tool, permissions.
• Run a minimal registered WSC hello-world test outside IIS. Confirm .wsc XML/registration syntax and COM creation.
• Record tested registration/unregistration commands and path/bitness behavior.
• Record unsupported assumptions and needed adaptations in docs/DECISIONS.md. Gate: a WSC can be registered, instantiated, called, unregistered, and re-registered on target Windows. MET — see docs/TEST-RESULTS.md.

M1 — Vertical HTTP slice

• Create thin Default.asp, Application.wsc, and HomeController.wsc.
• Choose and test host-to-COM argument/response contract. If ASP intrinsic objects cannot be passed safely, implement minimal primitive adapter.
• Add explicit rewrite/deny rules; verify static-file bypass.
• Add registration/unregistration scripts and component/HTTP tests.
• Verify GET /hello = 200, expected content-type and exact body.
• Verify direct source access denied, broken component gives safe error, basic concurrency and clean re-registration. Gate: all M1 SPEC acceptance tests pass on IIS, or mark blocked with evidence; do not call the milestone done without host verification. MET — see docs/TEST-RESULTS.md (includes one real defect found and fixed: regsvr32 /u does not remove .wsc registration on this host).

M2 — Lifecycle and errors

• Define per-request context and response ownership.
• Explicit creation/cleanup of objects; no shared request state.
• Central unexpected/expected error handling; headers/body commitment tests.
• Add correlation-safe diagnostics. Gate: repeated/concurrent requests and failure cases behave predictably. MET — see docs/TEST-RESULTS.md. HTTP response correctness holds unconditionally under concurrency (8/8 correct every run); best-effort logging completeness under heavy concurrency is an accepted, documented tradeoff, not a gate failure.

M3 — Routing

• Explicit route map with GET/POST, literal routes first.
• Safe decoding/validation, 400/404/405, Allow header.
• No arbitrary URL-to-ProgID or URL-to-method dispatch. Gate: route matrix and malformed URL tests pass.

M4 — Views

• Safe separate template loading, text-context encoding, default-deny for private templates.
• Template missing/escaping tests; add layout after renderer works. Gate: output is deterministic and untrusted text does not become HTML.

M5 — Data

• ADODB contract and provider-specific integration test database.
• Parameterized operations, transaction ownership, cleanup on error. Gate: real DB integration tests pass and input is not concatenated into SQL values.

M6 — Hardening

• Authentication/authorization design and security regression tests.
• Production logging and deployment rollback.
• Concurrent load and performance baseline with stated host specs. Gate: documented security and performance results.

M7 — Developer experience

• Component generator and interface-contract validator.
• Reproducible clean-room deployment/test guide.
• Review and propose evidenced AGENTS/CLAUDE improvements. Gate: another developer can reproduce setup and first request from docs.