Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

4.5KB

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. MET — see docs/TEST-RESULTS.md. WSH covers full Router/Application routing contract; IIS HTTP covers GET/POST-routed behavior and malformed route handling. PUT/DELETE can be intercepted by IIS before Classic ASP on the tested host, so those are not treated as framework HTTP-route assertions.

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. MET for the vertical slice shipped — see docs/TEST-RESULTS.md. Views/Layout.html (a layout convention) is not yet added since there is still only one view; add it when a second view needs shared chrome, not speculatively.

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. MET — see docs/TEST-RESULTS.md. Includes one real defect found and fixed during testing (LocalDB is unreachable from the IIS ApplicationPoolIdentity worker process; pivoted to a network-reachable SQL Server with SQL auth) and one caught in the diagnostic code itself (a chained On Error Resume Next masked the real failure reason). Identifier allowlisting (SPEC SS9) is not yet exercised — no route takes a table/column name from input in this vertical slice; deferred until one does, not implemented speculatively.

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.

Powered by TurnKey Linux.