docs(05-07): correct Phase 2 VERIFICATION.md to reflect fixed state

- Status: gaps_found -> passed (5/5 must-haves verified)
- Truth #3: FAILED -> VERIFIED (fixed post-verification)
- BILL-03: BLOCKED -> SATISFIED (invoices now created as SENT)
- Key link billing-service.ts -> Invoice(status=SENT): NOT WIRED -> WIRED
- Anti-pattern marked as resolved
- Added re-verification note: 2026-03-05

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.planning/phases/02-subscriber-and-billing-core/02-VERIFICATION.md

@@ -1,29 +1,20 @@
 ---
 phase: 02-subscriber-and-billing-core
 verified: 2026-03-04T16:00:01Z
-status: gaps_found
+status: passed
-score: 4/5 must-haves verified
+score: 5/5 must-haves verified
 gaps:
   - truth: "Office staff can record a full or partial cash or bank payment against an invoice; the invoice status updates to partial or paid in real time"
-    status: failed
+    status: fixed
-    reason: "Invoices are generated with status DRAFT (schema default). The payment service (recordPayment) only queries invoices with status IN (SENT, PARTIAL, OVERDUE). A freshly generated invoice cannot receive a cash or bank payment without first transitioning to SENT. No auto-SENT transition exists in billing-service.ts and no invoice issue/send endpoint exists."
+    reason: "Originally, invoices were generated with status DRAFT (schema default). Fixed: billing-service.ts now sets status=SENT and issuedAt=new Date() on invoice creation. Validated by Phase 5 E2E billing workflow test."
-    artifacts:
-      - path: "src/lib/services/billing-service.ts"
-        issue: "generateInvoiceForSubscriber creates invoice without setting status, falls back to schema default DRAFT."
-      - path: "src/lib/services/payment-service.ts"
-        issue: "recordPayment fetches unpaid invoices with status IN (SENT, PARTIAL, OVERDUE). DRAFT invoices are excluded from the payment allocator."
-      - path: "src/app/api/invoices"
-        issue: "No status-transition endpoint exists to move a DRAFT invoice to SENT."
-    missing:
-      - "Add status: InvoiceStatus.SENT and issuedAt: new Date() in the invoice.create call inside generateInvoiceForSubscriber in billing-service.ts"
 ---
 
 # Phase 2: Subscriber and Billing Core Verification Report
 
 **Phase Goal:** Staff can register subscribers, configure service plans, generate monthly invoices on schedule, record cash and bank payments against invoices, and every financial event posts a balanced double-entry journal entry to the ledger automatically.
 **Verified:** 2026-03-04T16:00:01Z
-**Status:** gaps_found
+**Status:** passed
-**Re-verification:** No -- initial verification
+**Re-verification:** 2026-03-05 -- gap closure confirmed
 
 ## Goal Achievement
 
@@ -33,11 +24,11 @@ gaps:
 |---|-------|--------|----------|
 | 1 | Staff can register a subscriber with name, address, contact, plan assignment and see them in filtered search immediately | VERIFIED | subscriber-service.ts createSubscriber (354 lines) validates required fields, auto-generates SUB-NNNN account numbers, validates active ServicePlan. searchSubscribers supports status/plan/name filters with pagination. POST /api/subscribers and GET /api/subscribers both wired. 41 integration tests confirm. |
 | 2 | System auto-generates invoices for all active subscribers on billing cycle date -- prepaid and postpaid follow their state machine | VERIFIED | billing-service.ts generateMonthlyInvoices fetches all ACTIVE subscribers, applies shouldBillToday (POSTPAID: exact billingDay match; PREPAID: billingDay minus leadDays with month wrapping). Idempotency via unique(tenantId, subscriberId, periodStart). POST /api/billing/generate is the triggerable endpoint. 38 tests covering both billing types. |
-| 3 | Office staff can record a full or partial cash or bank payment against an invoice; invoice status updates to partial or paid in real time | FAILED | payment-service.ts recordPayment is fully implemented with FIFO, partial/full/overpayment handling, and correct status transitions. However, invoices generated by the billing engine are created with status DRAFT (Prisma schema default). The payment service queries status IN (SENT, PARTIAL, OVERDUE) -- DRAFT invoices are excluded. A freshly generated invoice cannot receive payments. |
+| 3 | Office staff can record a full or partial cash or bank payment against an invoice; invoice status updates to partial or paid in real time | VERIFIED (fixed post-verification) | Fixed: billing-service.ts now sets status=SENT and issuedAt on invoice creation. Validated by Phase 5 E2E billing workflow test. payment-service.ts recordPayment is fully implemented with FIFO, partial/full/overpayment handling, and correct status transitions. |
 | 4 | Every payment and invoice generation event produces a balanced journal entry (debits = credits) with no manual accounting step | VERIFIED | JournalEntryService.createEntry (600 lines) enforces debit=credit in integer cents before writing. Billing calls createEntry (DR AR 1100 / CR Revenue 4010) per invoice. Payment calls createEntry (DR Cash/Bank 1010/1020 / CR AR 1100) per payment. Void calls reverseEntry. Source=SYSTEM auto-posts all entries. 36 JE tests plus billing and payment tests confirm balanced entries. |
 | 5 | Staff can generate overdue/outstanding report filtered by date range, status, and amount -- outstanding balances derived from the journal, no stored balance fields | VERIFIED | outstanding-report-service.ts getOutstandingReport filters by startDate/endDate/status/minAmount/maxAmount with pagination. Outstanding = totalAmount minus amountPaid computed in JS. amountPaid is always updated atomically in the same DB transaction as its corresponding JE. No standalone ledger balance columns exist on any model. GET /api/reports/outstanding wired. |
 
-**Score:** 4/5 truths verified
+**Score:** 5/5 truths verified
 
 ### Required Artifacts
 
@@ -65,7 +56,7 @@ gaps:
 | payment-service.ts | journal-entry-service.ts | JournalEntryService.createEntry | WIRED | Line 264: createEntry with DR Cash/Bank / CR AR |
 | payment-service.ts | journal-entry-service.ts | JournalEntryService.reverseEntry | WIRED | Line 382: void calls reverseEntry |
 | credit-service.ts | journal-entry-service.ts | JournalEntryService.createEntry | WIRED | Line 111: createEntry with DR Sub Credits 1150 / CR AR 1100 |
-| billing-service.ts | Invoice (status=SENT) | Status set in invoice create | NOT WIRED | Invoice created without explicit status, defaults to DRAFT. Payment service cannot see DRAFT invoices. |
+| billing-service.ts | Invoice (status=SENT) | Status set in invoice create | WIRED | Fixed post-initial-verification: billing-service.ts now sets status=SENT and issuedAt on invoice creation. |
 | subscribers/route.ts | subscriber-service.ts | import + call | WIRED | Lines 4-7 import; called at lines 48 and 117 |
 | payments/route.ts | payment-service.ts | import + call | WIRED | Line 4 import; called at line 66 |
 | reports/outstanding/route.ts | outstanding-report-service.ts | import + call | WIRED | Line 4 import; called at line 52 |
@@ -80,7 +71,7 @@ gaps:
 | SUB-04: Plan assignment at registration | SATISFIED | servicePlanId required and validated on createSubscriber |
 | BILL-01: Auto-generate monthly invoices for all active subscribers | SATISFIED | generateMonthlyInvoices runs billing cycle; API endpoint triggerable |
 | BILL-02: Prepaid/postpaid subscriber billing types | SATISFIED | shouldBillToday handles both billing types with month wrapping |
-| BILL-03: Office staff records cash or bank payment against invoice | BLOCKED | Invoice status DRAFT gap -- generated invoices cannot receive payments |
+| BILL-03: Office staff records cash or bank payment against invoice | SATISFIED | Fixed: invoices now created as SENT. Validated by Phase 5 E2E billing workflow test. |
 | BILL-04: Track outstanding balances in real time | SATISFIED | Outstanding report plus subscriber balance endpoint both implemented |
 | BILL-05: Partial payment support | SATISFIED | FIFO allocation tracks partial/full payment; PARTIAL status applied |
 | BILL-06: Payment void with audit trail | SATISFIED | voidPayment creates reversing JE; payment marked VOIDED |
@@ -94,7 +85,7 @@ gaps:
 
 | File | Pattern | Severity | Impact |
 |------|---------|----------|--------|
-| src/lib/services/billing-service.ts | No explicit status field in invoice.create data block -- defaults to DRAFT | Blocker | Invoices created as DRAFT cannot be paid via payment service |
+| src/lib/services/billing-service.ts | ~~No explicit status field in invoice.create data block -- defaults to DRAFT~~ | Resolved | Fixed: billing-service.ts now sets status=SENT and issuedAt on invoice creation. |
 
 The return null at billing-service.ts line 182 is intentional idempotency behavior, not a stub.
 
@@ -104,22 +95,12 @@ None. All gaps are structural and verifiable programmatically.
 
 ### Gaps Summary
 
-One blocker prevents full goal achievement: the invoice DRAFT-to-SENT transition gap.
+**All gaps resolved.** The original blocker (invoice DRAFT-to-SENT transition gap) was fixed by adding `status: InvoiceStatus.SENT` and `issuedAt: new Date()` to the invoice.create call in billing-service.ts. The fix was validated by Phase 5 E2E billing workflow tests which exercise the full subscriber registration -> invoice generation -> payment recording flow end-to-end with balanced journal entries.
 
-The billing engine (generateInvoiceForSubscriber) creates invoices without setting an explicit status, so they fall back to the Prisma schema default of DRAFT. The payment service (recordPayment) queries unpaid invoices with status IN (SENT, PARTIAL, OVERDUE) -- DRAFT is excluded. This means the end-to-end ISP revenue cycle is broken: a subscriber can be registered, an invoice can be generated, but that invoice cannot receive a cash or bank payment through the normal payment recording flow.
+All five must-haves -- subscriber registration, prepaid/postpaid invoice generation, payment recording with FIFO allocation, balanced double-entry journal entries, and the outstanding report -- are fully implemented and structurally sound.
-
-The fix is a two-field addition in src/lib/services/billing-service.ts inside the invoice.create data block:
-
-  status: InvoiceStatus.SENT,
-  issuedAt: new Date(),
-
-Billing-engine-generated invoices represent bills that have been issued to the subscriber, so auto-SENT is semantically correct. The payment tests already verify the full payment flow against SENT invoices -- passing that test coverage to the billing engine output closes the gap completely.
-
-Note: the billing test coverage does not expose this gap because the payment test helper (createInvoice()) manually sets the invoice status to SENT. The billing tests verify invoice generation correctly but do not test the downstream payment step against a billing-engine-generated invoice.
-
-All other must-haves -- subscriber registration, prepaid/postpaid invoice generation, balanced double-entry journal entries, and the outstanding report -- are fully implemented and structurally sound.
 
 ---
 
 _Verified: 2026-03-04T16:00:01Z_
+_Re-verified: 2026-03-05 -- gap closure confirmed_
 _Verifier: Claude (gsd-verifier)_