What Actually Changed
Since the last field note, we shipped meaningful work across preconstruction, marketing, purchasing, payroll, and the release system. New intake paths became durable. Review surfaces became more task-focused. Provider writes gained stronger idempotency and reconciliation. A shared release engine replaced two drifting deployment paths.
But the most important progress began when a payroll feature reached real operations and the individual parts did not add up to one usable workflow.
Time could be reviewed. Provider delivery could be planned. Processed payroll could be acquired. Accounting proposals could be composed. Each capability had tests. Yet required reference data could still be missing at the moment of use, an externally completed step had no first-class receipt, and proposal creation could depend on the exact UI event that happened to precede it. The code had features. The operator did not yet have a closed loop.
That distinction changed our definition of done.
Shipped Work: One Payroll Chain
The payroll work now has a declared operating unit: one tenant-scoped payroll run. Readiness composes the evidence for that run instead of asking an operator to infer the state of several loosely related screens.
Approved time freezes the operational facts. Provider delivery has durable, independently idempotent intents. Processed-payroll acquisition waits for a stable provider snapshot instead of treating the first balanced read as final. Finance composition combines payroll authority with the job and classification lineage the payroll provider does not carry. Posting uses approved commands, stable request identities, exact readback, and reconciliation before retry. Unknown outcomes fail closed and remain repairable.
This is more than a longer happy path. Manual and coexistence states are represented instead of being treated as embarrassing exceptions. A rerun reuses existing intent, receipt, checkpoint, and proposal identities. A posted correction is a linked reversal or corrective transaction, never an invisible delete.
The release path changed in parallel. Local and hosted releases now execute the same phase graph, validation receipts are bound to source and target, and a shared lease prevents two normal releases from mutating the runtime at once. Release evidence became part of the product's operating memory.
Decisions And Tradeoffs: Recovery Is Architecture
The tempting design was to let each integration own its slice and join the results later. That is how a balanced payroll result can lose project lineage, or a successful provider call can become indistinguishable from an unknown outcome after a local persistence failure.
We chose a more explicit division of authority. The payroll provider owns final payroll facts. The field-service system owns work and project facts. The accounting platform owns the posted ledger. LKCI owns the reviewed policy, cross-system lineage, durable intent, and recovery state that make those facts composable.
That choice adds machinery. It requires immutable snapshots, typed blockers, versioned mappings, command ledgers, receipts, and repair jobs. The alternative is not simplicity. It is forcing an operator to reconstruct a distributed transaction from several vendor screens and our logs.
The later integration-boundary refactor made the same principle executable. Provider-shaped requests, authentication, pagination, and errors belong in the integration. Provider-neutral contracts belong in libraries. Business sequencing, approval, durable state, leases, and recovery belong in services. The cutover removed compatibility facades rather than preserving two writable paths indefinitely.
Collaboration Evolution: The Step Back Was The Work
The decisive prompt in this period was not a feature request. I asked us to step back and explain why so many production steps had appeared only after the feature was supposedly complete. Codex's review reached the uncomfortable conclusion: we had delivered individual capabilities without validating the complete operational lifecycle.
That changed the working relationship in three observable ways.
First, I challenged the placement of provider-specific payroll normalization. The first fix worked, but the provider vocabulary had leaked into shared reconciliation. We moved the classification to the provider boundary and made the generic workflow consume a canonical category. The architectural question was not an after-the-fact cleanup; it changed the contract before we relied on the fix broadly.
Second, we stopped treating worker completion as integration proof. Bounded implementation and audit streams could run with lower-cost models, but the coordinator still had to reconcile the complete diff, persistent models, migration graph, existing-data behavior, and release gates. That experience is now encoded in the repository's data-model development governance.
Third, I asked for certainty before deployment. Codex refused to call any production change “zero risk” and replaced the impossible promise with a conditional go/no-go case: exact-source validation, production preflight, quiescence, migration reconciliation, readiness checks, and post-release verification. Trust improved because the agent constrained the claim instead of matching the requested confidence.
Validation: What The Evidence Supports
The implementation record includes deterministic adapter, policy, repository, service, job, API, and UI tests; disposable migration and webhook acceptance; controlled accounting-provider canaries; rendered payroll review checks; and combined predeploy validation. The release task subsequently reported a successful migration, coordinated service rollout, readiness verification, and post-deploy checks through the shared engine.
That evidence supports a narrow claim: the repository now has a coherent, tested operating chain and a governed way to release it. It does not prove that every future payroll, provider response, or deployment will succeed. A sandbox write is not authority for a production write. A green migration test is not evidence that no new production state can appear. The controls matter because the world remains capable of disagreeing with the plan.
Lessons
The lesson is not that every feature needs a giant framework. It is that the unit of completion has to match the unit a person operates.
For money movement and external effects, “the endpoint works” is much too small. Completion includes the facts required before the action, the authority to approve it, the identity of the effect, the evidence returned afterward, and the path for an unknown or partial result. If any of that exists only in a conversation, the feature is borrowing reliability from memory.
This period also made architecture more empirical. The boundary rules were not invented because layered diagrams look tidy. They were earned by watching provider vocabulary leak inward, duplicate execution paths drift, and local success fail to produce an operator-visible next step.
Unresolved Work
Payroll provider coexistence is intentionally temporary, and production accounting writes remain separately gated. The broader repository has not yet adopted the new model-contract inventory for every historical table; adoption is risk-weighted, beginning with money movement, external effects, operator decisions, and repair paths.
The harder open question is whether this definition of done holds under the next large feature. The test is not whether we can add another gate. It is whether intent, authority, evidence, and recovery are designed together before operations has to discover the missing link.