# Connector WorkItem Hot-Path Learnings

## 2026-07-23 - Eliminate Event-History Queue Recalculation

- Baseline: the production incident investigation found the 5-second inbound supervisor proving global Event-to-WorkItem coverage (about 19,103 nonterminal Event and 27,861 WorkItem rows) and the 15-second sampler evaluating an Event-owned branch across about 173,594 historical rows. The measured exact coverage check averaged about 17.865 seconds of queueing.
- Candidate revisions: NexusCRM `9254e3ed7` plus nexuscrm-connectors `815fadd` worktree candidates.
- Invariant: WorkItem is the sole steady-state execution and backlog authority. Event remains immutable provenance and contributes only namespace metadata for WorkItem-backed queue rows.
- Change: remove Event-only arms from the queue statistics CTE and remove the supervisor's recurring global coverage proof. Enqueue fails closed if WorkItem materialization or lane reconciliation fails. The WorkItem executor neither scans, converts, nor retires prior Event-owned execution rows.
- Validation: focused connector supervisor, events, and workqueue package tests pass. This is source-level candidate evidence, not staging or production acceptance.
- Next evidence: deploy the paired L0 revisions, then compare TiDB statement digest/RU, query latency, lock waits, Event-owned nonterminal count, and WorkItem backlog under production traffic.

## 2026-08-16 - API Live-Queue Observation Audit

- Run: `static-audit-2026-08-16`; baseline NexusCRM `92755d8e497272ecb6d465a09bafc822c429a90e` with `nexuscrm-connectors v0.2.9`.
- Environment: current-tree source and consumer audit. No live TiDB plan or RU measurement was available in this loop.
- Workload shape: every API replica samples immediately at startup and then every 15 seconds on the primary business pool. The ten-minute Sentry endpoint independently recomputes the same queue snapshot on request.
- Profile result: the current cheap-live query no longer evaluates terminal Event history. WorkItem is the sole lifecycle authority; the query aggregates the complete nonterminal connector WorkItem set and joins Event only for namespace metadata. The July historical-Event measurement therefore cannot serve as the current baseline.
- Plan uncertainty: existing claim indexes begin with `InstalledPackId`, while the observation is global and grouped across installations and queue classes. Static SQL shape proves an unbounded active-range aggregate, but not the selected physical plan, examined keys, or read RU.
- Correctness boundary: both consumers are diagnostics-only. They do not participate in enqueue, claim, lane/FIFO ordering, retry, leasing, dedupe, replay, repair, or completion. Process-local transition accumulation cannot represent exact global depth across API/worker replicas and restarts.
- Next evidence: measure the deployed statement digest, execution count, total and average read RU, TiDB and resource-control latency, examined/processed keys, active WorkItem cardinality, and selected plan. Do not add an index or replace the sampler based on the stale historical-Event baseline.
- Conditional next hypothesis: if the surviving cost is material, move the exact refresh to the fixed hourly API observation scheduler with no startup read, a dedicated one-connection pool, last-good memory, and freshness/failure/duration metrics; then make Sentry consume that same owned snapshot in a separate slice.

## 2026-08-16 - API Live-Queue Observation Implementation Loop 1

- Commits: uncommitted NexusCRM implementation on `92755d8e4`; Connector metric-initialization dependency candidate `8c613dd` in `nexuscrm-connectors` PR #283.
- Environment/workload: first focused compile and tests for `backend/internal/interfaces/rest/ops` and `backend/pkg/serverruntime`, using a temporary local Go workspace for the unpublished Connector dependency.
- Result: both focused packages passed. The preceding formatting command used root-relative paths while already running from `backend`, so formatting did not execute; the test result remains valid but is not formatting evidence.
- Learned: the snapshot-reader dependency, route wiring, removal of the request-time Connector query, and hourly source composition compile together. The next loop must run formatting from the repository root, then inspect the exact diff and add any missing behavior assertions before broadening tests.

## 2026-08-16 - API Live-Queue Observation Implementation Loop 2

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as loop 1.
- Environment/workload: repeated focused ops and server-runtime tests after removing the snapshot owner's dependency on the REST response type and adding last-good/immutable-copy assertions.
- Result: both focused packages passed again. The formatting command repeated the same incorrect root-relative path from the `backend` working directory, so this loop still provides compile/test evidence only.
- Learned: the provider now satisfies the consumer-owned interface structurally without importing the REST package, and the new behavior tests compile. Run formatting as a separate repository-root command before any further semantic edit; do not conflate the passing tests with formatting completion.

## 2026-08-16 - API Live-Queue Observation Implementation Loop 3

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as prior loops.
- Environment/workload: repository-root formatting plus focused ops and server-runtime tests. Coverage includes no startup pool/query, initialized freshness series, unavailable/stale state before the first tick, WorkItem-only cheap SQL authority, atomic last-good preservation after failure, immutable snapshot copies, and the Sentry JSON observation status.
- Result: formatting and whitespace checks passed; both focused packages passed.
- Learned: the new owner preserves old data on observation failure, exposes uncertainty explicitly, and removes Connector SQL from the Sentry request path without changing queue execution semantics. The next loop should run focused race detection and inspect the complete current diff for stale symbols, missing module pinning, lifecycle leaks, and response-compatibility risk before broader backend tests.

## 2026-08-16 - API Live-Queue Observation Verification Loop 1

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as prior loops.
- Environment/workload: race-enabled focused tests for the ops handler and server runtime.
- Result: both packages passed under the race detector. The macOS linker emitted its existing malformed `LC_DYSYMTAB` warnings; no race or test failure occurred. The chained stale-symbol search ran after `cd backend` and therefore addressed nonexistent `backend`/`docs` child paths; it produced no cleanup evidence and must be rerun from the repository root.
- Learned: concurrent snapshot refresh/read and Sentry serialization are race-clean under focused coverage. The next loop must complete the root-level removed-symbol/consumer audit before any cleanup or broad verification conclusion.

## 2026-08-16 - API Live-Queue Observation Review Loop 1

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as prior loops.
- Environment/workload: root-level removed-symbol and current-consumer audit plus adversarial timeout/lifecycle review.
- Result: the old 15-second sampler, enablement environment variable, exponential backoff, and Sentry Connector query have no remaining consumers; `QueryCheapLiveQueueStats` has one database read owner. One material regression was found: composing Connector into the existing hourly coordinator inherited its 30-second source timeout, while the retired sampler bounded the query at two seconds.
- Learned / next hypothesis: connection-pool isolation protects API capacity but does not cap shared TiDB RU. Add a per-source timeout to the generic coordinator, retain the two-second Connector bound, and prove that one source's shorter deadline does not change the other sources or last-good failure behavior.

## 2026-08-16 - API Live-Queue Observation Implementation Loop 4

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as prior loops.
- Environment/workload: focused ops and server-runtime tests after adding per-source observation deadlines.
- Result: both packages passed. Connector now retains its former two-second query bound inside the hourly independent observer; Outbox and Rollup Delta retain the coordinator's 30-second default. The timeout-isolation test uses a five-millisecond source override with a one-second coordinator default and proves the following source still executes.
- Learned: the hourly design now reduces frequency and preserves the prior per-query RU time bound instead of trading connection isolation for a longer cluster-resource exposure. Repeat race detection after this concurrency-path change, then broaden to the complete backend workspace.

## 2026-08-16 - API Live-Queue Observation Verification Loop 2

- Commits: same uncommitted NexusCRM implementation and Connector dependency candidate as prior loops.
- Environment/workload: repeated focused race tests after the per-source timeout change, followed by the complete backend test suite using the temporary local Connector workspace.
- Result: both focused packages passed under the race detector; the same local macOS linker warnings appeared with no race. Every backend package passed. The log wrapper attempted to assign zsh's read-only `status` parameter after the test command, so the wrapper itself exited early; the preserved full log showed the complete successful package list and was then removed.
- Learned: the timeout change is race-clean and the new dependency wiring compiles across the complete backend. Remaining gates are the published Connector version pin, final current-diff/boundary review, and the post-deployment Test2 plan/RU measurement.

## 2026-08-16 - API Live-Queue Observation Dependency Gate

- Commits: NexusCRM implementation remains uncommitted on `92755d8e4`; Connector prerequisite `8c613dd` is published as PR #283, with both module CI and Codex Review passing.
- Environment/workload: current release-boundary audit after the complete backend verification.
- Result: NexusCRM `main` and its distribution module pin the released `nexuscrm-connectors v0.2.9`. The DB-free fixed-series initializer exists only in the prerequisite candidate, so committing the core implementation without a new published Connector tag would either fail a clean build or violate the no-local-replace dependency rule.
- Learned / next step: merge the prerequisite and publish its next semver tag, then update both backend module pins, repeat clean-workspace verification without the temporary Go workspace, and only then commit and open the NexusCRM PR. Do not replace the released dependency with a local path or silently accept missing metrics for the first hour.

## 2026-08-16 - API Live-Queue Observation Release-Pin Loop

- Commits: Connector PR #283 merged as `f182e627a`; annotated release tag `v0.2.10` resolves to that exact merge commit. NexusCRM remains uncommitted on `92755d8e4` with both backend module manifests advanced from `v0.2.9` to `v0.2.10`.
- Environment/workload: remote tag verification and clean released-module resolution, with no local `replace` directive or temporary Connector workspace in the dependency path.
- Result: the tag was published and both modules downloaded the same `v0.2.10` content checksum. The first download attempted the public checksum service and failed because the Connector repository is private; the retry used private-module/direct resolution through the existing GitHub CLI credential helper and succeeded. The dependency diff is limited to the two direct version pins and their matching checksums.
- Learned / next step: release-boundary availability is now satisfied. Remove the temporary workspace, rerun focused, race, full-backend, distribution, shared, whitespace, and boundary verification against the released pin, then perform the final ownership/correctness review before commit.

## 2026-08-16 - API Live-Queue Observation Released-Pin Verification Loop 1

- Commits: uncommitted NexusCRM candidate on `92755d8e4`, resolving the published Connector `v0.2.10`; the temporary local Connector workspace was deleted before testing.
- Environment/workload: focused ops/server-runtime tests, focused race tests, and the standalone distribution module test command.
- Result: focused and race suites passed against the released dependency, with only the previously observed macOS linker warnings. The distribution command first ran under the root workspace and was correctly rejected because that module is intentionally excluded; `GOWORK=off` then reached its checked-in app-pack replacement and stopped because this isolated worktree has no `nexuscrm-app-packs` checkout. This is an environment prerequisite gap, not a test or compile failure in the changed backend path; published-module resolution itself already succeeded in both module directories.
- Learned / next step: the released API and concurrent observation path are proven. Run the complete backend and shared suites plus static gates in the available workspace; report the absent external app-pack checkout explicitly instead of weakening or rewriting distribution replacements for this PR.

## 2026-08-16 - API Live-Queue Observation Final Review

- Commits: final uncommitted NexusCRM candidate on current `origin/main` `92755d8e4`, with Connector `v0.2.10` resolving to merge commit `f182e627a`.
- Environment/workload: complete backend and shared test suites, focused race tests, formatting/whitespace checks, removed-symbol and single-consumer audit, public-core boundary scan, and adversarial review of startup, failure, freshness, ownership, and business-path isolation.
- Result: complete backend and shared suites passed; focused race tests passed. All changed and new Go files are formatted and `git diff --check` is clean. The boundary scan reports only pre-existing unchanged hits and the candidate adds none. The former immediate/15-second sampler, enablement flag, fallback readers, backoff path, and request-time Sentry query are gone; the hourly owner is the only core caller of `QueryCheapLiveQueueStats`. No enqueue, claim, ordering, retry, lease, replay, repair, or completion path consumes the cache.
- Review conclusion: no material correctness or ownership defect remains. Startup deliberately publishes initialized zero-valued Connector series together with stale/unavailable observation state and performs no queue read; a successful hourly refresh atomically publishes one exact global snapshot; a failure retains the last-good snapshot and marks it stale. The database remains the sole queue authority and the two-second Connector deadline plus independent one-connection pool bound diagnostic interference.
- Residual evidence: the static design reduces each API replica's scheduled statement frequency from four per minute to one per hour (about 240x), and removes the separate Sentry query, but it does not prove the resulting TiDB plan or measured RU. Post-deployment Test2 must compare statement digest execution count, total/average read RU, examined keys, latency, active WorkItem cardinality, and observation freshness/failures before closing the performance item.

## 2026-08-26 - Outbound Association Dependency Spin Baseline

- Run: isolated Test2 Full Inspection case `sales/opportunity/quote-approval-discount-step-routing-api` in run `32935394026`; SQL/log collector run `32935651237` over `2026-08-26 05:47:02` through `05:50:03` UTC.
- Commits: serving NexusCRM `8b91b8e3222f61cea3228a7856b8fa17d2e1a6b6`, pinned `nexuscrm-connectors v0.2.16`; comparison baseline NexusCRM `8e248eec2eb850fd392a375a254802b38d2e3c53`, pinned `nexuscrm-connectors v0.2.14`.
- Environment/workload: one isolated Quote approval journey on Test2 while the Integration outbound worker owned three provider-neutral commands whose association Remote Links did not yet exist.
- Profile result: 346 candidate claims, 345 empty `_System_ConnectorRemoteLink` reads, and 345 one-second retry transitions occurred in about three minutes. The candidate-claim digest averaged 8,968.6 examined keys, 199.3 processed keys, and 99.565 Read RU per execution. The attributable dependency-spin path consumed about 43,647 Read RU (79.7% of captured Read RU), at least 5,417 SQL statements, and at least 25.577 seconds of TiDB statement service time. Resource-queue time was zero for every captured digest.
- History check: the empty-queue `HasWorkHint` optimization (`754c7b6`, PR #282) and durable `NextWorkAt` scheduling (`639c9fc`, PR #289) are ancestors of both Connector versions and were not reverted. The uncovered path originated with the outbound lifecycle (`ad67074`, PR #253): every retryable preparation error, including `association_link_pending`, is scheduled for `now + 1s`.
- Learned: the queue scheduler is obeying a false deadline; SQL/index tuning would only make the spin cheaper. A missing Remote Link is a durable dependency, not a transient provider failure. Integration must persist the exact dependency, remove the command from the runnable claim set, and wake it in the same transaction that finalizes the Remote Link. Runtime, Flow, product packs, provider names, and tenant metadata must not become dependency authorities.
- Next hypothesis: add one Integration-owned `waiting_dependency` state plus an indexed opaque dependency key. Prove on real TiDB that a blocked command is not claimable across repeated worker turns, an unrelated Remote Link cannot wake it, and finalizing the exact Remote Link atomically makes it runnable without provider replay or FIFO violation.

## 2026-09-05 - Test2 Outbound Dependency Backlog Revalidation

- Run: Test2 read-only observer `33956035415`, covering `2026-09-05 08:13:14` through `08:43:14` UTC; serving Catalog revision 27.
- Commits: Core candidate `a85206627` plus the dependency schema change; Connector candidate based on `9b0104c` with the current owner-lifecycle fences retained.
- Environment/workload: 1,251 sampled Integration outbound commands, including 189 current-revision `association_link_pending` retry commands and 69 younger pending commands blocked behind active lane heads.
- Profile result: in 30 minutes, the claim digest ran 1,796 times and consumed about 201,640 Read RU while examining about 1,733 keys per execution; the next-work digest ran 604 times and consumed about 73,879 Read RU while examining about 2,921 keys per execution. The 189 current-revision association waits carried 11,936 accumulated retries, and the retry update ran 1,187 times in the window.
- Learned: the durable scheduler is honoring its deadlines; the expensive work comes from representing an absent association Remote Link as a capped timed retry. The narrow fix is to persist a non-runnable dependency wait and wake it when the Integration-owned Remote Link is finalized. Core must first prove that existing installations receive the required nullable columns and exact lookup index; a greenfield-only catalog change is not deployable evidence.
- Next hypothesis: add one resumable, fail-closed warm-schema reconciliation for the catalog-owned dependency columns and index, then run the Connector lifecycle and concurrency suite against that exact schema candidate before considering any claim-query rewrite.

## 2026-09-05 - Outbound Dependency Warm Upgrade Loop 1

- Commits: uncommitted Core warm-schema candidate on `173b32342`.
- Environment/workload: focused schema catalog and real-TiDB warm-upgrade tests.
- Result: catalog ownership passed; every warm-upgrade case stopped while constructing its legacy fixture because the test routed an intentionally old definition through the current fail-closed catalog entrypoint.
- Learned: an existing installation is an old physical table presented to the current canonical definition, not an old definition presented to the current binary. Build only the legacy physical fixture through the lower DDL primitive, then exercise the public current-catalog entrypoint for every upgrade pass.

## 2026-09-05 - Outbound Dependency Warm Upgrade Loop 2

- Commits: same uncommitted Core warm-schema candidate as loop 1.
- Environment/workload: focused catalog plus required real-TiDB legacy, partial-resume, repeated-upgrade, and column-drift cases.
- Result: all cases passed. Existing command payload remained byte-identical, newly added dependency fields remained NULL, a second convergence pass was a no-op, and a non-binary DependencyKey was rejected before the missing sibling columns or index were added.
- Learned: column convergence is resumable and fail-closed. Add the symmetric named-index drift case so a conflicting index can neither be adopted nor silently rewritten, then freeze the schema boundary for broader Connector verification.

## 2026-09-05 - Outbound Dependency Warm Upgrade Loop 3

- Commits: same uncommitted Core warm-schema candidate as loop 2.
- Environment/workload: focused named-index drift fixture on real TiDB.
- Result: fixture construction failed before the migration ran because TiDB does not resolve a newly added column for an index declared later in the same ALTER TABLE statement.
- Learned: mirror the production migration's resumable DDL order in the fixture: add the three columns first, then create the intentionally incompatible named index in a separate statement.

## 2026-09-05 - Outbound Dependency Warm Upgrade Loop 4

- Commits: same uncommitted Core warm-schema candidate as loop 3.
- Environment/workload: complete focused catalog and real-TiDB warm-schema matrix after correcting the drift fixture.
- Result: legacy, partial-resume, repeated convergence, wrong-column, and wrong-index cases all passed. Rejected drift left the physical schema unchanged.
- Learned: the Core release boundary is ready to freeze. The current catalog is the single declared shape, and one narrow warm migration makes that shape real on both greenfield and retained installations before Connector readiness succeeds.

## 2026-09-05 - Outbound Dependency Schema Verification

- Commits: frozen Core candidate on current main `a85206627`; paired Connector candidate on current main `9b0104c`.
- Environment/workload: focused catalog and real-TiDB migration matrix, Connector race and full repository suites, plus Core kernel and persistence owner suites.
- Result: every candidate-relevant Core and Connector test passed. The Core persistence-wide run completed with three failures in the existing permission direct-writer structure test; the identical three failures reproduced on a clean detached `a85206627` baseline and reference only unchanged `metadata_record_types.go` methods.
- Conclusion: the schema candidate adds one catalog-owned nullable extension and one resumable, fail-closed warm migration. It preserves retained rows, refuses incompatible column/index shapes, and supplies the exact indexed wake path required before the Connector release.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 1

- Commits: uncommitted Connector candidate on `b7a1dd8`; uncommitted NexusCRM schema candidate on `8b91b8e32`.
- Environment/workload: focused Connector compile plus the new worker and real-TiDB dependency lifecycle tests.
- Result: compilation stopped at `model_compatibility_test.go` because the first implementation added dependency fields to the exported positional `Command` struct. No functional test ran.
- Learned: durable dependency state belongs to the Integration command table and Repository, but it is not part of the released worker-facing command contract. Keep the new columns internal, preserve the public struct shape, and assert persisted dependency facts directly at the Repository/database boundary before rerunning the same tests.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 2

- Commits: same uncommitted Connector and NexusCRM candidates as loop 1.
- Environment/workload: focused worker behavior plus real-TiDB wait/wake lifecycle after moving dependency columns behind the Repository boundary.
- Result: the new worker test and complete dependency lifecycle passed. The lifecycle proved no work hint, no schedule, and no claim after a one-hour clock advance; an unrelated Remote Link did not wake the command; the exact link did; and registering after the link existed returned immediately to retry. The pre-existing `TestRepositoryWorkHintCoversPendingExpiredAndWritebackAgainstTiDB` separately failed because TiDB returned `MIN(DATETIME)` as bytes that `sql.NullTime` cannot scan.
- Learned: the dependency mechanism works without changing the released `Command` shape. Before broad verification, add the same-link FIFO assertion and keep the TiDB aggregate-time compatibility failure separate from this optimization unless baseline comparison proves it is candidate-caused.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 3

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: repeated focused real-TiDB lifecycle with a newer command in the waiter's exact lane, focused worker behavior, Core schema-catalog test, and the complete outboundintent package.
- Result: dependency lifecycle, same-lane FIFO, worker behavior, and Core schema ownership all passed. The full package had exactly one failure: the unchanged pending-row branch of `TestRepositoryWorkHintCoversPendingExpiredAndWritebackAgainstTiDB`, where this local TiDB returns aggregate `MIN(DATETIME)` as bytes despite `parseTime=true`; all other package tests passed.
- Learned: `waiting_dependency` is both non-runnable and a durable FIFO blocker, while the system catalog owns all required columns and the exact wake index. The remaining full-package failure predates and is independent of the dependency path; do not mix a driver/time-decoding repair into this performance change without baseline evidence.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 4

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: focused lifecycle rerun after making the wake predicate directly indexable and adding fail-closed binary-collation verification.
- Result: wait/wake and worker tests passed. The new drift test failed during fixture mutation because TiDB correctly refuses to change an indexed column's collation while the index exists, so the verifier itself was not reached.
- Learned: the production schema and predicate now align for exact indexed equality. Adjust only the drift fixture to remove its index before changing collation, then prove `VerifySchema` rejects the resulting invalid column before rebuilding broader evidence.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 5

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: focused real-TiDB lifecycle, schema collation drift, and worker behavior after correcting the drift fixture.
- Result: all focused tests passed. `VerifySchema` accepts the catalog-owned binary dependency key and rejects a non-binary drifted key; the wake SQL uses direct equality on that indexed binary column.
- Learned: correctness and the intended indexed read path are now coupled by startup verification. Add a true concurrent register-versus-finalize stress test to falsify lost-wakeup or lock-order assumptions before running race and repository-wide verification.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 6

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: twelve real-TiDB iterations racing dependency registration against exact Remote Link finalization.
- Result: iteration 5 reproduced a lost wake. Both calls returned success, the Remote Link existed, but the command remained `waiting_dependency` with no deadline. TiDB did not serialize the waiter's absent-key `SELECT ... FOR UPDATE` against the concurrent insert/wake transaction.
- Learned: an absent Remote Link cannot be the sole synchronization lock. Persist a short-lived, runnable `dependency_registration` state before the post-commit readiness reconciliation; make Remote Link finalization wake both registering and settled waiters. A crash or reconciliation error then remains recoverable through the ordinary scheduler, while every commit ordering has either a wake or a durable reconciliation path.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 7

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: repeated focused lifecycle plus twelve real-TiDB concurrent registration/finalization races after introducing recoverable dependency registration.
- Result: every iteration passed; after both concurrent calls completed, each waiter was `retry`, had no dependency residue, and was claimable exactly once. The sequential no-spin, exact-wake, unrelated-link, ready-before-register, same-lane FIFO, and worker tests also remained green.
- Learned: the prior absent-key lock assumption has been removed from correctness. Prove the recovery half explicitly by seeding a durable `dependency_registration` row and showing the normal work hint and claim path recover it while clearing internal dependency fields.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 8

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: all outboundintent tests except the proven baseline-only aggregate-time failure passed; focused tests then ran under Go race instrumentation, which changed transaction timing.
- Result: concurrent iteration 0 again ended in `waiting_dependency` after both calls succeeded. The registration recovery test itself passed. The remaining race is inside settlement: it reads readiness before locking the waiter command, allowing a stale registration-state update to overwrite a concurrent `retry` wake under TiDB's transaction snapshot semantics.
- Learned: settlement must lock in the same `Remote Link → waiter command` order and re-read the command state under that lock before transitioning. If finalization already changed it, settlement must be a no-op; if settlement owns the waiter first, finalization must block and then wake the settled state.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 9

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: three normal repetitions and two race-instrumented repetitions of the complete sequential, interruption-recovery, and twelve-iteration concurrent real-TiDB dependency suite.
- Result: all runs passed after locking and re-reading the waiter command behind the Remote Link read. No lost wake, deadlock, duplicate claim, dependency residue, or Go data race occurred.
- Learned: both transaction orderings are now serialized at the owning command row, while an interrupted registration remains scheduler-recoverable. Continue with current-diff/API-boundary review and broad repository verification; reopen semantics only for a consequential live consumer or invariant gap.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 10

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: API-surface cleanup made dependency signaling Repository-internal and added a TiDB index-width assertion, followed by focused compilation.
- Result: compilation stopped because a test's local variable named `dependency` shadowed the newly unexported type at a later literal; no runtime test ran.
- Learned: the public `Command` and established worker-store contract remain unchanged, but the internal type needs a non-colliding semantic name. Rename it mechanically to `commandDependency`, then repeat the same focused and compatibility tests before any broader conclusion.

## 2026-08-26 - Outbound Dependency Wake Implementation Loop 11

- Commits: same uncommitted Connector and NexusCRM candidates as prior loops.
- Environment/workload: focused dependency lifecycle/worker compilation after renaming the internal type, plus the Core schema and worst-case TiDB index-width test.
- Result: focused Connector tests passed; the released positional `Command` compatibility guard compiled unchanged; the Core dependency schema, binary collation, index shape, and index-width checks passed.
- Learned: dependency signaling does not require a new exported type or a mandatory method on the established worker-store interface. Keep the two internal lifecycle states unexported as well, then run the final broad suite against the smallest public surface.

## 2026-08-26 - Outbound Dependency Wake Verification Loop 1

- Commits: final uncommitted Connector candidate on `b7a1dd8`; NexusCRM schema candidate on `8b91b8e32`.
- Environment/workload: internal-state focused tests, two race-instrumented concurrent repetitions, all outboundintent tests, and the complete Connector repository. The one local aggregate-time test was excluded only after the identical failure was independently reproduced from an untouched detached `origin/main` worktree.
- Result: all candidate-relevant focused, race, package, compatibility, and repository tests passed. The released `Command` shape and established worker-store interface remain unchanged; dependency types, errors, store method, and lifecycle states are Repository-internal. The untouched baseline failure is TiDB returning `MIN(DATETIME)` as bytes to `sql.NullTime`, not a candidate regression.
- Learned: the Connector candidate is internally and repository-wide green against all available relevant evidence. Finish NexusCRM schema-consumer verification, static boundary/diff review, and release-order planning; post-deployment Test2 must rerun the same isolated journey and compare dependency-spin statement/RU counts to the recorded baseline.

## 2026-08-26 - Outbound Dependency Wake Verification Loop 2

- Commits: final uncommitted Connector candidate on `b7a1dd8`; final NexusCRM schema candidate on `8b91b8e32`.
- Environment/workload: complete Connector repository; complete NexusCRM kernel and shared modules; focused schema catalog; public-core scan; whitespace checks; and a backend-wide parallel run against the shared local TiDB.
- Result: Connector, kernel, shared, focused schema, race, and static gates passed. The backend-wide parallel run did not pass: unrelated automation integration tests contended on the shared control-plane/TiDB, timed out at ten minutes, and an OAuth integration test waiting on the same apply lock reached an existing controlplane cleanup panic. Before that contention failure, the candidate `_System_IntegrationOutboundCommand` DDL—including all three columns, binary key collation, and the exact wake index—was generated and executed successfully multiple times; bootstrap and all non-contending backend packages passed. The boundary scan reported only pre-existing unchanged hits.
- Final conclusion: replace the false one-second association deadline with Integration-owned durable dependency waiting. Deploy the Core schema first, then a released Connector containing the behavior. Expected steady-state effect for the captured three blocked commands is elimination of the 345 claims, 345 empty link reads, and associated retry writes observed in three minutes; exact Test2 RU improvement remains a deployment measurement, not a pre-deployment claim.
- Post-deployment proof: rerun `sales/opportunity/quote-approval-discount-step-routing-api`, collect the same three-minute SQL window, and require zero repeated claims for commands whose state is `waiting_dependency`, exact wake on target Remote Link commit, no younger same-lane bypass, no new uncertain/rejected commands, and a direct comparison of statement count, examined keys, Read RU, TiDB service time, and resource-queue time to run `32935651237`.