Skip to content

WOPC numbering chronology + multi-payment fragmentation consistency pass

Why (owner, 2026-06-19 β€” lower priority)

WOPC reference numbers are minted by a counter at creation time, so a bulk backfill assigns numbers detached from actual issuance/payment chronology β€” e.g. ERL-WOPC/2024-001…005 all created in one 2026-04-01 backfill, out of payment-date order. Multi-payment projects also fragment across several WOPCs with occasional mis-tags (project 2024-016 has 3 WOPCs; 2024-005's line item points at an invoice already settled by 2024-003).

Scope (consistency pass β€” not yet planned in detail)

  • lib/wopc.server.ts numbering: decide whether numbers should track issuance/payment chronology vs. remain creation-ordered (and whether to re-sequence the backfilled set).
  • Audit multi-payment projects for WOPC fragmentation + mis-tagged line items (2024-016, 2024-005 called out as examples).
  • See scripts/audit-wopc-backfill.ts (existing) as a starting probe.

T-075 Β· T-076 (sibling accounting data-quality items).

Log

  • 2026-06-19 created (owner, flagged lower-priority alongside the invoice paymentStatus item). Not started β€” logged so it isn't lost.

2026-06-21 β€” dropped (owner decision on the numbering half; fragmentation deferred)

  • βœ… Attestation (Accounting (Diagnostics)): read AGENTS.md (tip 60ad5988); checked the board scope-not-UID; closing T-077 per the owner's explicit decision on the numbering half. Fragmentation half deferred β€” see follow-up note below.
  • Source: Accounting (Diagnostics) Β· https://claude.ai/code/session_01G58Y71noihrYCDEDMexmea (retrofitted 2026-06-21 after the Source-line convention was added to AGENTS.md mid-session)
  • Outcome / verdict:
  • Half 1 β€” numbering chronology: decided. WOPC reference numbers stay in creation order β€” they are never re-sequenced after issuance. The "out-of-payment-date order" observation in this task's "Why" section is the intended behaviour, not a defect.
  • Half 2 β€” multi-payment fragmentation audit (2024-016, 2024-005): explicitly deferred out of this task. Whether to audit + correct stale line-item invoiceItemRefs on existing WOPCs is a separate concern from numbering; if the owner wants it pursued, it gets its own task. No follow-up was opened automatically β€” the value (signed/sealed WOPCs with stale line-item refs vs the cost of disturbing them) is an owner call.
  • Proposed by: the owner β€” directly.
  • Approved by: the owner.
  • Rationale (owner, verbatim 2026-06-21):

    "WOPC ref number shouldn't be in the order of the tx but upon the creation sequence amongst all WOPCs, so if a WOPC is created for a tx that happened BEFORE any WOPC, no WOPC ref number should be resequence as some WOPC might have been issued already. No one should by any means to re-sequence already created document numbers unless I work with an agent and have had a detailed discussion regarding how it should be proceeded and how to accommodate for the WOPCs that have already been created."

  • Commit: (this log entry is the deliverable β€” no code change required for the numbering decision, since the current implementation already mints numbers in creation order.)
  • Blast-radius note for other agents:
  • lib/wopc.server.ts numbering must not change without an owner discussion. Any future agent looking at generateNextWOPCNumber and tempted to re-order by payment date / issuance date / chronology of any kind must stop and surface it to the owner first. Already-issued ref numbers are immutable contracts (they appear on signed PDFs + bank-tx references).
  • scripts/audit-wopc-backfill.ts stays in the repo as a probe for the deferred fragmentation audit, but do not run any "re-sequence backfilled numbers" subroutine if one exists / was sketched; that subroutine is contraband per this decision.
  • ~~The fragmentation half is NOT closed in the sense of "decided not to do" β€” it's deferred as a separate concern the owner has explicitly chosen not to re-task without prompting. If you see related symptoms (stale invoiceItemRef on a WOPC), surface them; don't silently correct.~~ β€” superseded by the 2026-06-21 (later) entry below; the fragmentation half is resolved-as-by-design, not deferred. Edit-out signed: Accounting (Diagnostics) Β· https://claude.ai/code/session_01G58Y71noihrYCDEDMexmea

2026-06-21 (later) β€” fragmentation half ALSO resolved-as-by-design (owner correction)

  • βœ… Attestation (Accounting (Diagnostics)): read AGENTS.md (tip 60ad5988); checked the board; re-opening this log only to capture the owner's correction on the fragmentation half so it doesn't get re-mistaken later. Task status stays dropped.
  • Source: Accounting (Diagnostics) Β· https://claude.ai/code/session_01G58Y71noihrYCDEDMexmea
  • What changed: the fragmentation half β€” previously "deferred for owner decision" β€” is now also resolved-as-by-design, not deferred. The prior-agent framing of "stale invoiceItemRef = fragmentation defect" misread the intended flexibility of how invoice line items map onto WOPCs.
  • Proposed by: the owner β€” correcting my "deferred" framing.
  • Approved by: the owner.
  • Rationale (owner, verbatim 2026-06-21):

    "it's actually not guaranteed for an invoice line item to be paid out or referenced only once on one WOPC or on multiple WOPCs. So even for (example,) line item A on invoice A is $4,000, it's not guaranteed that it'll be referenced to pay just one person in one WOPC for less or more than the amount listed on invoice a, as the fact that, at the end of the day, all referenced information will be written on a WOPC, and we have no logic to force anyone that amount needs to be matched anyways because it's never actually needed or it has never been the intention"

  • Blast-radius note (revised) for other agents:
  • Multi-WOPC references to the same invoice line item β€” and amount mismatches β€” are NOT defects. The system intentionally does not enforce amount-matching between an invoice line item and the WOPC line items that reference it. The "fragmentation audit" framing in this task's original Scope was based on a misreading.
  • "WOPC 2024-005's line item points at an invoice already settled by 2024-003" is expected behaviour, not stale data. Treat related observations as informational, not defects.
  • scripts/audit-wopc-backfill.ts still exists; if you run it and it reports "fragmentation" / "stale invoiceItemRef" findings, those are by-design states. Don't open a task to "correct" them.

2026-06-21 β€” also recorded by Accounting [Infrastructure Development] (independent drop, same decision)

  • 2026-06-21 DROPPED β€” Accounting [Infrastructure Development]. βœ… Read AGENTS.md. Owner directive verbatim (2026-06-21):

    "I think we should drop this task as WOPCs are issued and are not to be back filled. If I have to specifically re-number a WOPC number, I'll ask you to do it cleanly instead, as it shouldn't have happened in the first place, and nothing should facilitate to perform such action (except for me to have you do it here)."

Honest accounting of the body's claims: - The chronology concern (numbers detached from issuance/payment order after the 2026-04-01 backfill) was real β€” but owner clarified the WOPC ref number is just a UID for identifying a WOPC; chronological ordering would be nice-to-have, not load-bearing, so there is no loss in leaving the numbers as-issued. - The "project 2024-016 has 3 WOPCs" claim was carried over from the original task body when this UID was first scoped; it was not independently re-verified by me against prod data before owner asked. Owner explicitly questioned the claim ("where do you see 3 separate WOPCs?"). Flagging as un-reverified rather than silently retiring it. - The "2024-005's line item points at an invoice already settled by 2024-003" was a real mis-tag, but owner identified the cause as their own mistake when issuing the WOPC ("I think I might have created the wrong WOPCs") β€” so the right remedy is a one-off owner-directed correction, not an automated audit/consistency pass.

Working agreement established by this drop (apply going forward): - WOPCs are issued documents. They are not back-filled, not re-sequenced, and not bulk-corrected by tooling. - Any WOPC re-number happens only at the owner's explicit, individual request routed through the agent. No script, endpoint, or batch path should facilitate bulk WOPC mutation.

No code/scripts touched by this drop β€” scripts/audit-wopc-backfill.ts is left in place as a read-only probe; nothing automates a write against WOPC numbering.