Breaks down the design into an atomic, ordered, and verifiable task plan.

/sdd-tasks <change-name>

• The design artifact (the file matrix and approach):

  • mem_search(query: "sdd/{change-name}/design")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: design content passed inline from orchestrator.
• The spec artifact (the success criteria):

  • mem_search(query: "sdd/{change-name}/spec")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: spec content passed inline from orchestrator.
• The proposal artifact — specifically the

  ## Supersedes

  section:

  • mem_search(query: "sdd/{change-name}/proposal")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: proposal content passed inline from orchestrator.

• Types/interfaces before their usage
• Providers/services before their consumers
• Schema/migration before the code that uses them
• Unit tests alongside the code (not at the end)
• Removals and replacements BEFORE additions (see Step 3 below)

1. Read

   ## Supersedes

   from proposal.md.
2. If section is absent (older archived change): log

   INFO: no Supersedes section in proposal.md — skipping removal task generation

   and proceed to Step 4 with standard phase organization.
3. If section states "None — purely additive change": skip removal task generation; proceed to Step 4.
4. If section has REMOVED or REPLACED items: proceed to Step 3b.

• Generate one task titled

  Remove: [feature name]

  with:
  • File paths to delete or modify
  • Acceptance criterion: "File deleted AND no runtime errors in related flows"
  • Spec reference: linked spec requirement name (if spec exists for this removal)

• Generate two tasks in dependency order:

  1. Remove old: [old feature name]

     — delete/unregister the old implementation

  2. Implement new: [new feature name]

     — add the replacement (link to spec requirement)
• Note explicit dependency: task 2 cannot start until task 1 is complete.

• 1.1 Remove: [feature name] from

  path/to/file

  Linked spec: [Requirement name from spec, or "N/A — no spec for this removal"] Files:

  path/to/file

  (DELETE),

  path/to/other.ts

  (remove registration/import) Acceptance: File deleted AND related flows continue without runtime errors
• 1.2 Remove old: [old feature name] from

  path/to/old-file

  Linked spec: [Requirement: Replacement requirement name] Files:

  path/to/old-file

  (DELETE or MODIFY) Acceptance: Old implementation fully removed; no lingering imports or references
• 1.3 Implement new: [new feature name] in

  path/to/new-file

  Linked spec: [Requirement: new feature requirement] Depends on: 1.2 Files:

  path/to/new-file

  (CREATE or MODIFY) Acceptance: New implementation active; spec scenarios pass

⚠️ Phase 2 MUST NOT begin until all Phase 1 tasks are complete.

undefined

• MUST_RESOLVE

  — A warning that blocks implementation until the user provides an explicit answer. Use this when:
  • The task involves a business rule decision that has multiple valid interpretations
  • The task depends on an external system behavior that is ambiguous (e.g., which field to use in an API response)
  • The task cannot be implemented correctly without knowing the user's intent
  • Example reason:

    "business rule decision — external system behavior is ambiguous"

• ADVISORY

  — A warning that is logged for awareness but does not block implementation. Use this when:
  • The concern is a performance consideration that does not affect functional correctness
  • The concern is a style or naming preference with no impact on task completion
  • The concern is informational and the implementer can safely proceed without further input
  • Example reason:

    "performance consideration — does not affect correctness"

  • Example reason:

    "style or naming preference — no impact on current task"

tasks.md

- [ ] X.Y Task description [WARNING: MUST_RESOLVE]
  Warning: [human-readable warning text]
  Reason: [classification reason, e.g., "business rule decision — external system field ambiguous"]
  Question: [clarifying question derived from the warning]

- [ ] X.Y Task description [WARNING: ADVISORY]
  Warning: [human-readable warning text]
  Reason: [classification reason, e.g., "performance consideration — does not affect correctness"]

• Warnings appear immediately below their task entry, indented with two spaces
• A task may have at most one warning entry (combine multiple concerns into one if needed)
• Tasks without warnings have no indented block below them

- [ ] 2.1 Create `src/services/payment.service.ts` with method `processPayment(dto: PaymentDto): Promise<PaymentResult>` [WARNING: MUST_RESOLVE]
  Warning: Stripe invoice field for failure date is ambiguous — `status_transitions.marked_uncollectible_at` vs `status_transitions.voided_at` may both apply depending on invoice state.
  Reason: business rule decision — external system behavior is ambiguous
  Question: Which Stripe invoice field should be used to record the payment failure date?

mem_save

topic_key: sdd/{change-name}/tasks

type: architecture

project: {project}

undefined

• 1.1 Create

  src/types/auth.types.ts

  with interfaces

  LoginRequest

  ,

  LoginResponse

  ,

  JwtPayload

• 1.2 Create

  src/schemas/auth.schema.ts

  with Zod schemas for login validation
• 1.3 Modify

  src/config/jwt.config.ts

  — add

  refreshSecret

  and

  refreshExpiresIn

• 2.1 Create

  src/services/auth.service.ts

  with methods

  login()

  ,

  logout()

  ,

  refreshToken()

• 2.2 Modify

  src/repositories/user.repository.ts

  — add

  findByEmail()

  method
• 2.3 Create

  src/middleware/auth.middleware.ts

  for JWT validation on protected routes

• 3.1 Create

  src/controllers/auth.controller.ts

  with endpoints POST /login, POST /logout, POST /refresh
• 3.2 Modify

  src/routes/index.ts

  — register auth routes
• 3.3 Modify

  src/app.ts

  — integrate auth middleware on protected routes

• 4.1 Create

  tests/unit/auth.service.spec.ts

  — unit tests for AuthService
• 4.2 Create

  tests/integration/auth.controller.spec.ts

  — endpoint tests
• 4.3 Verify scenario coverage from spec (review engram:sdd/[name]/spec)

• 5.1 Update

  README.md

  — document new endpoints
• 5.2 Update

  ai-context/architecture.md

  if there were structural changes

• [important note 1]
• [important note 2]

• [blocker]: [what resolves it]

---

• HARD STOP: My only output is

  tasks.md

  + the JSON block. I NEVER implement any task, write code, or modify project files beyond creating tasks.md
• Each task MUST have a concrete file path
• Each task MUST be atomic (single responsibility)
• Each task MUST be verifiable (can be marked done with certainty)
• Tests go with their code, not all at the end
• Phase order respects technical dependencies
• Documentation and memory tasks (ai-context) go in the last phase
• I do NOT include tasks that go beyond the proposal's scope
• If I detect that the design is incomplete to generate tasks, I report it as a blocker