CtrlK
BlogDocsLog inGet started
Tessl Logo

wagneripjr/doc-this

Reverse-engineer a legacy codebase into ATDD-ready, traceable specifications

69

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

tasks-template.mdskills/doc-this-writer/references/

Template — <unit>/tasks.md

Structure

# Tasks — <unit name>

Each task is scoped to a single externally observable behavior, references the legacy source, and has a clear done-criterion. Confidence is mandatory.

## Implementation tasks

### Task 1 — Implement POST /api/orders (place a new order)
- **Done-criterion**: `@api` scenario "Place a new order with valid items" passes against the new implementation.
- **Legacy source**: `OrdersController.cs:42`, `OrdersService.cs:60-95`
- **Acceptance scenario**: `requirements.md` → "Place a new order with valid items"
- **Protocol driver to implement**: `IOrdersPublicApiDriver`
- **Confidence**: 🟢

### Task 2 — Implement POST /api/orders rejection for inactive subscriptions
- **Done-criterion**: `@api` scenario "Reject order for inactive subscription" passes.
- **Legacy source**: `OrdersService.cs:88`
- **Acceptance scenario**: `requirements.md` → "Reject order for inactive subscription"
- **Confidence**: 🟢

### Task 3 — Implement /orders/new UI page
- **Done-criterion**: `@browser` scenario "Submit order through the UI" passes.
- **Legacy source**: `pages/OrderForm.tsx:1`
- **Acceptance scenario**: `requirements.md` → "Submit order through the UI"
- **Protocol driver to implement**: `IOrdersBrowserDriver`
- **Confidence**: 🟢

### Task 4 — Wire orders.created publisher
- **Done-criterion**: When an order is finalized, an `orders.created` event lands on the broker. Validated as a side effect of @api scenario.
- **Legacy source**: `OrderService.cs:91`
- **Confidence**: 🟢

### Task 5 (only when database_ownership = external/mixed) — Honor external invoice procedure
- **Done-criterion**: `@database` scenario "Order finalization invokes the legacy invoice procedure" passes.
- **Legacy source**: `InvoiceService.cs:142`
- **Acceptance scenario**: `requirements.md` → "Order finalization invokes the legacy invoice procedure"
- **Protocol driver to implement**: `IInvoiceDatabaseContractDriver`
- **Confidence**: 🟢

## Protocol drivers to implement

(generated by doc-this-promote when this spec is promoted; listed here as a placeholder)

- `IOrdersPublicApiDriver` — bridges @api scenarios to a real HTTP client
- `IOrdersBrowserDriver` — bridges @browser scenarios to Playwright/Cypress
- `IInvoiceDatabaseContractDriver` — bridges @database scenarios to the live (test) DB

## Open gaps (🔴) blocking implementation

- 🔴 Lockout policy after N failed payment attempts (from requirements.md gaps section). Resolve before Task 2 implementation.

Notes

  • Each task is named after an external behavior — never after an internal class or method.
  • Done-criterion ties to a specific scenario in requirements.md.
  • Protocol driver to implement field exists when the task crosses an external boundary; the actual interface declaration lives in docs/design/protocol-drivers.md after doc-this-promote runs.
  • Confidence on every task. No exceptions.
  • Open gaps section gates implementation — items there must be resolved (promoted to 🟢 with a citation in requirements.md) before the task starts. Per the describe-only pact, confidence is binary 🟢 / 🔴 only — no 🟡.

tile.json