Amend ADR 0014 for pull-based KB ingestion

Context

#11730 tracks post-MVP deployment residuals from Discussion #11718. One residual is #11731: server-side repo-clone / pull-based tenant KB ingestion, gated until the MVP push-based model (#11726) proves insufficient.

ADR 0014 shipped via PR #11738 for D0 / #11721. It correctly classifies the current kbSync scheduler lane as local-only for the MVP cloud profile because that lane means the Neo maintainer checkout sync / local ai:sync-kb cascade path.

A future #11731 implementation may introduce a different cloud-deployable pull-ingestion path: the deployment pulls tenant repos using an explicit credential/token/env-var contract. If that happens, future agents need an authorized way to amend or distinguish ADR 0014 instead of getting stuck in the paradox: ADR says kbSync is local-only, but the post-MVP feature work is trying to prove a cloud pull-sync path.

The Problem

Without a tracked ADR-amendment escape hatch, #11731 can become logically blocked by the current ADR even when new evidence proves the premise has changed.

The current ADR authority is precise but MVP-scoped:

• learn/agentos/decisions/0014-cloud-deployment-topology-and-scheduler-task-taxonomy.md:39 classifies kbSync as local-only because the current lane scans the Neo repo checkout and cascades after a dev pull.
• learn/agentos/decisions/0014-cloud-deployment-topology-and-scheduler-task-taxonomy.md:73 says the standalone kbSync lane needs a deployment-mode disable toggle.
• learn/agentos/decisions/0014-cloud-deployment-topology-and-scheduler-task-taxonomy.md:120-121 rejects feeding cloud tenant content by re-pointing the local kbSync lane at tenant content.
• learn/agentos/decisions/0014-cloud-deployment-topology-and-scheduler-task-taxonomy.md:134 leaves server-side repo cloning as D3 / out of scope.
• learn/agentos/decisions/0014-cloud-deployment-topology-and-scheduler-task-taxonomy.md:149-150 defines re-review triggers for lane classification changes.

That is correct for the current lane. It must not become permanent authority against a later, explicitly designed pull-ingestion lane with a credential boundary.

The Architectural Reality

There are two distinct concepts that future work must not conflate:

1. Maintainer-checkout kbSync — the existing local-only lane that scans Neo's own checkout and is part of local maintainer machinery.
2. Tenant pull-ingestion — a possible post-MVP cloud ingestion mode from #11731, where the deployment pulls tenant repo content under an explicit credential, repo identity, refresh-cadence, and secret-handling contract.

ADR 0014 currently names the first concept. #11731 may decide whether the second concept exists, whether it is a new lane, a renamed/split kbSync class, or a distinct ingestion service path.

The Fix

When #11731 reaches a concrete decision, update the decision substrate so agents are not forced to choose between stale ADR obedience and implementing a valid post-MVP capability.

The implementation may be one of:

• amend ADR 0014 to distinguish maintainer-checkout kbSync from tenant pull-ingestion;
• add a follow-up ADR that supersedes the relevant kbSync taxonomy row for the pull-ingestion case;
• explicitly close this ticket if #11731 rejects server-side pull ingestion or proves it remains outside the scheduler taxonomy.

Contract Ledger

Gating Condition

Do not start this ticket independently. It starts only after #11731 produces evidence that one of these is true:

• pull-based tenant KB ingestion is adopted for post-MVP cloud deployment; or
• #11731 explicitly needs ADR 0014 clarified before its implementation can proceed.

Until then, this issue is a dormant escape hatch under #11730.

Acceptance Criteria

• #11731 has produced a decision or implementation plan that explicitly adopts, rejects, or scopes pull-based tenant KB ingestion.
• ADR 0014 is amended or followed up if pull-ingestion changes the scheduler/task taxonomy or the meaning of kbSync.
• The resulting decision distinguishes maintainer-checkout kbSync from tenant pull-ingestion, or states why no distinction is needed.
• Credential/token/env-var handling is cited before any cloud pull-ingestion path is marked deployable.
• If pull-ingestion is rejected or remains out of scheduler scope, this issue is closed with the rationale instead of producing a no-op ADR edit.

Out of Scope

• Implementing server-side repo clone / pull ingestion itself — owned by #11731.
• Changing the #11720 MVP cloud profile.
• Reopening ADR 0014 for unrelated scheduler lanes.
• Treating #11730 as an active ADR workstream before #11731's gate fires.

Avoided Traps

Related

• Parent epic: #11730
• Blocking / gating input: #11731
• Current ADR authority: #11721 / PR #11738 / ADR 0014
• MVP push-ingestion baseline: #11726 / PR #11737
• Watchpoint comment: #11730 comment IC_kwDODSospM8AAAABDP4zhA

Origin Session ID

4435cdc7-4380-4643-9721-ecef2c705a11

Handoff Retrieval Hints

• query_raw_memories(query="pull sync KB ADR 0014 local-only kbSync #11730 #11731")
• query_raw_memories(query="ADR 0014 pull-based tenant ingestion paradox")