feat(integrations): shared-layer enrollment + target-collection plumbing (#505, #506)

[mavaali]

Summary

Stacked slices 1–2 of the accepted M365 ingestion design (#492, spec docs/superpowers/specs/2026-08-31-m365-selected-ingestion-design.md). No M365-specific code in either — the shared layer that a selected-source adapter (#508) will build on.

Closes #505 — provider-neutral enrollment in the shared connector layer

• src/integrations/types.ts: "m365" joins ProviderName (with an optional config block so config[provider] indexing stays typed); new EnrollmentRecord (ref, kind: "file" | "folder", label, targetCollection, enrolledAt, enrolledBy); ProviderState gains optional enrollment and opaque adapter-owned adapterData. Absent fields = existing google/notion behavior.
• src/integrations/engine.ts: optional ProviderAdapter.resolveEnrollment(candidates, state) capability; the provisional-cursor discipline now also snapshots/restores adapterData (deep-copied) — intermediate writes keep the replayable values, commit only when no source in the page failed; UnavailableSourceEvent.reason widens to no_longer_discovered | access_denied | deleted | unenrolled; ReconcileLimits gains an optional maxCycleMs soft wall-time cap.
• src/integrations/routes.ts: the provider route matcher derives names from the registered adapters instead of the hardcoded (google|notion) regex.
• src/integrations/state.ts / runtime.ts: validation for the new fields; DEFAULT_FACTORIES becomes Partial with a named error if a configured provider has no factory.

Closes #506 — thread targetCollection through the integration distill path

• src/distill/propose.ts / state.ts: DistillIds/DistillUpsertInput gain an optional collection override, defaulting to DISTILL_COLLECTION; derivePath and the frontmatter.collection field use it. Every existing caller (no override passed) is unaffected.
• src/integrations/engine.ts: DistillationInput gains targetCollection?: string; RemoteSource gains an optional enrolledRef so a folder-enrolled provider can attest which enrollment record owns a discovered descendant. The reconcile loop looks up the owning EnrollmentRecord (exact ref match, or enrolledRef for a folder descendant) and threads its targetCollection into deps.distill(). google/notion carry no enrollment, so they see no behavior change.
• src/integrations/distill.ts forwards targetCollection into the distillUpsert collection field.
• refuseRawDistillOutput needed no code change — it is purely structural (path + frontmatter.tier), so it already fires identically against an overridden collection; added tests proving it.
• New requireCollectionWriteAccess(role, targetCollection) reuses canWrite — the same stage-time write-gate rationale as vault_stage_action (docs/architecture.md "Stage-time write gate"): manage_integrations alone must not let an enrollment aim proposals at a collection the serve process cannot write. feat(m365): File Picker page, enrollment routes, cost preview, and status surfaces #509's enroll route will call this before persisting an EnrollmentRecord.

Test plan

• npm run lint — 0 errors/warnings (6 pre-existing infos)
• npm run build — clean
• npm test — full suite shows only the 30 known environmental failures (Read-path fence: kill condition 1 fired — decide whether to accept the kill or fund a larger pre-registered run #314), identical to main
• New behavior has tests:
  • feat(integrations): provider-neutral enrollment in the shared connector layer #505: fake enrolled-provider adapter proving discover() = "expand the enrollment set"; adapterData replay (failed source keeps cursor+adapterData replayable, success commits both); maxCycleMs; route matcher; state round-trip + malformed-enrollment rejection
  • feat(distill): thread targetCollection through the integration distill path #506: collection override lands proposals/paths under it (propose.ts, state.ts); default path unchanged for existing callers; fence fires identically for an overridden collection including raw; engine threads targetCollection from the owning enrollment record (direct file match and folder-descendant enrolledRef match); google/notion unaffected; requireCollectionWriteAccess allows/denies by role, including the null-role deny-all fallback
  • existing google/notion tests unchanged and green throughout

Invariants

• Frontmatter stays the only metadata layer; the SQLite index stays derived/ephemeral (enrollment/adapterData live in the existing encrypted integrations envelope, metadata-only)
• Curation stays advisory
• RBAC is config-driven — the new gate reuses canWrite against the existing .daftari/config.yaml roles, no new permission model
• Error handling stays Result<T, Error>; no classes; no throws from tool handlers

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BgaRyc5Nji2GpMYwXEYpmk

[mavaali]

CI red on build (22) at 4178890, but it's not this PR's: the single failure is test/sleep/vanished-source-wake.test.ts > wakes a fresh canonical dependent with the last commit that contained its deleted source, with

Error: ENOTEMPTY: directory not empty, rmdir '/tmp/daftari-sleep-vanished-4vJJo3/.git/objects'

— a filesystem-cleanup race in that test's tmp-git-repo teardown, in src/sleep//test/sleep/, which this PR never touches (only src/distill/, src/integrations/, and their tests). Everything else passed: 403/404 test files, 4785/4786 tests. No fix exists for this yet; re-running the failed job once to confirm the flake.

---

Generated by Claude Code

[claude]

Review summary

The core plumbing for M365 selected-source ingestion (#505/#506) — enrollment records, owningEnrollment, the collection-name path-safety fence (isValidCollectionName), requireCollectionWriteAccess, adapter-data snapshotting, maxCycleMs, provider-neutral routing — is solid, well-commented, and has matching test coverage in test/distill/ and test/integrations/. No violations of the CLAUDE.md hard invariants (no classes, Result<T, Error> throughout, frontmatter-only metadata, RBAC stays config-driven, no auto-fixing curation).

However, the feature is currently unreachable end-to-end because three provider-enumeration sites outside this diff's touched files were not updated to include "m365" alongside ProviderName's widening:

1. src/utils/config.ts:549-553 (RECOGNISED_INTEGRATIONS_KEYS) and :607 (validateIntegrations's provider loop) — still only recognize google/notion. An operator adding an integrations.m365: block to .daftari/config.yaml gets a hard failure: 'integrations.m365' is not a recognised setting. This file isn't touched anywhere in the diff.
2. src/integrations/runtime.ts:67 (configuredProviders) — still hardcoded to ["google", "notion"] as const. This is the list createConfiguredIntegrationRuntime uses to decide which providers get OAuth-credential validation, adapter construction, and periodic sync registration, so "m365" never reaches the runtime even if (1) is fixed. Left inline comment on this one.
3. src/integrations/queue.ts:94 (validQueueItem) — same hardcoded google/notion check; a queued m365 webhook/refresh-hint item would fail shape validation. Lower severity today since m365 has no webhook path yet, but it's the same class of gap and will resurface.

None of these three files have any m365-related test, which is presumably how the gap made it through — all the new tests exercise reconcileProvider and the encrypted state layer directly, never createConfiguredIntegrationRuntime or config-file loading with an m365 block.

Recommend fixing 1 and 2 before merge (2 is unreachable without 1); 3 can be a fast-follow but should track ProviderName for consistency with isProviderName in src/integrations/state.ts.