# Feature Specification: Spec 429 - Exchange/Teams Source Surface Catalog & Adapter Strategy

**Feature Branch**: `429-exchange-teams-source-surface-catalog-adapter-strategy`
**Created**: 2026-07-04
**Status**: Implementation complete - docs/catalog ready for review
**Input**: User-provided draft "Spec 429 - Exchange/Teams Source Surface Catalog & Adapter Strategy"

## Preparation Selection Summary

- **Selected candidate**: Spec 429 - Exchange/Teams Source Surface Catalog & Adapter Strategy.
- **Source location**: User-provided attachment `/Users/ahmeddarrazi/.codex/attachments/922413a0-883b-4d66-8436-a335f510e9e5/pasted-text.txt`.
- **Why selected**: The automatic candidate queue in `docs/product/spec-candidates.md` currently has no safe auto-prep target, but the user directly provided a P0 Coverage v2 / Microsoft 365 candidate. Specs 426-428 show the next Exchange/Teams blocker is not a single missing Graph contract; it is the absence of a coherent source-surface and adapter strategy.
- **Roadmap relationship**: This belongs to the M365 Coverage v2 readiness sequence after Specs 414, 415, 417, 419, 420, 422, 426, 427, and the prepared Spec 428 fail-safe/no-op package. It supports a later Exchange/Teams adapter cohort implementation without claiming readiness now.
- **Close alternatives deferred**: Management-report runtime validation, governance-artifact lifecycle retention, provider-readiness productization, cross-domain indicator follow-through, system-panel browser fixture work, and first governed AI runtime consumer remain manual-promotion/backlog items. They do not supersede this direct P0 Exchange/Teams continuation.
- **Completed-spec guardrail result**: Specs 414, 415, 417, 419, 420, 422, 426, and 427 contain completed implementation reports, validation results, completed tasks, or browser/smoke evidence. They are read-only dependency context and must not be rewritten, normalized, reopened, or stripped of close-out history. Spec 428 exists as a prepared fail-safe/no-op package and is accepted as non-blocking for this catalog-only spec because Spec 429 does not consume evidence or promote capture.
- **Smallest viable implementation slice**: Create documentation/catalog artifacts only: source reference notes, Exchange catalog, Teams catalog, target type matrix, cohort plan, adapter strategy, requirements checklist, and no-runtime implementation report. Do not implement adapters, provider calls, evidence, OperationRuns, UI, customer output, compare/render promotion, certification, restore, or runtime registry consumption.
- **Candidate Selection Gate**: PASS. The candidate is directly provided, not already covered by an existing Spec 429 package, aligns with the current Exchange/Teams blocker, and is scoped as a docs/catalog-only strategy package.

## Draft-To-Repo Deviations

The draft assumes Spec 428 can be treated as a fail-safe/no-op close-out. Current repo truth says Spec 428 is prepared but not implementation-closed; it records the fail-safe/no-op path because Spec 427 left all four first target types blocked as `contract_blocked_repo_adapter_missing`.

This spec proceeds only because it is catalog/strategy work and does not depend on runtime evidence from Spec 428. Any attempt to treat Spec 428 as implemented evidence, or to use Spec 429 to create evidence, must stop and move to a separate implementation spec after the source-adapter decision is ready.

The historical sequence "429 compare/render promotion" from Specs 426/427 is superseded by this user-provided 429 catalog/strategy candidate. Compare/render promotion is deferred to later Spec 432 after adapter implementation and content-backed evidence exist.

## Spec Candidate Check *(mandatory - SPEC-GATE-001)*

- **Problem**: Exchange/Teams Coverage v2 cannot progress safely while TenantPilot lacks a source-surface catalog and adapter strategy for the real Exchange Online, Teams, Security & Compliance, Graph, and Admin API boundaries.
- **Today's failure**: The previous narrow sequence tried to reason about four target types in isolation. Spec 427 proved those types remain blocked by missing repo adapters/source contracts, and Spec 428 correctly prepared a no-op instead of evidence promotion. Without Spec 429, future work may guess endpoints, implement one-off adapters, or overclaim M365 readiness.
- **User-visible improvement**: Release reviewers and later implementers get a clear map of which Exchange/Teams surfaces matter, which source surface can be trusted, which adapter pattern is required, which target types enter Cohort 1, and which claims remain blocked.
- **Smallest enterprise-capable version**: Documentation/catalog artifacts only: Exchange catalog, Teams catalog, target type matrix, Cohort 1/2/deferred plan, adapter strategy, and no-promotion proof. No runtime code.
- **Explicit non-goals**: No Exchange adapter, Teams adapter, Graph contract, PowerShell execution, Exchange Admin API client, provider permission change, provider call, runtime documentation lookup, evidence row, OperationRun, coverage-level promotion, compare/render, certification, customer report, Review Pack/PDF output, restore/apply flow, Exchange/Teams dashboard, new provider subsystem, `tenant_id`, legacy shim, or runtime registry consumption.
- **Permanent complexity imported**: Spec/catalog documentation vocabulary only. No runtime model, table, enum, service, adapter, provider client, UI concept, or persisted taxonomy is introduced by this spec. Later implementation specs must re-justify runtime complexity.
- **Why now**: Specs 426-428 prove fail-safe behavior but leave Exchange/Teams structurally blocked. The next safe action is to map source surfaces and adapter cohorts before any more runtime work.
- **Why not local**: A local fix for four types would repeat the problem. The blocker spans Exchange Online PowerShell, Teams PowerShell, Graph, Exchange Online Admin API, Purview/Security & Compliance, SharePoint/OneDrive boundaries, permissions, identity, redaction, and customer claims.
- **Approval class**: Core Enterprise.
- **Red flags triggered**: New documentation taxonomy and strategy vocabulary. Defense: it remains static Spec Kit documentation, is required to prevent false governance/customer claims, and explicitly defers all runtime machinery to later specs with proportionality review.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 1 | Wiederverwendung: 2 | **Gesamt: 11/12**
- **Decision**: approve as catalog/strategy-only preparation for later adapter implementation.

## Spec Scope Fields *(mandatory)*

- **Scope**: Workspace + managed-environment scoped Coverage v2 planning context; documentation/catalog only.
- **Primary Routes**: N/A - no route, page, navigation, panel, action, report, download, browser-rendered surface, or customer surface changes.
- **Data Ownership**: No runtime data changes. Catalog artifacts must preserve the current ownership language: workspace, managed environment, provider connection, provider-owned source metadata, and no platform-core `tenant_id`.
- **RBAC**: Existing RBAC remains unchanged. Later adapter implementation must define capability and authorization requirements before any capture or provider call.

For canonical-view specs:

- **Default filter behavior when tenant-context is active**: N/A - no canonical route or rendered query changes.
- **Explicit entitlement checks preventing cross-tenant leakage**: N/A for this spec. Later runtime capture must enforce workspace + managed-environment + provider-connection same-scope checks.

## No Legacy / No Backward Compatibility Constraint *(mandatory)*

TenantPilot is pre-production unless this spec explicitly records a compatibility exception.

- **Compatibility posture**: canonical documentation-only strategy; no compatibility exception.
- **Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?**: no.
- **Why clean replacement is safe now**: No runtime behavior changes. The spec explicitly forbids legacy adapters, fallback readers, dual writes, Coverage v1 bridges, `tenant_id` ownership truth, fake evidence fixtures, and customer-facing legacy claims.

## UI Surface Impact *(mandatory - UI-COV-001)*

Does this spec add, remove, rename, or materially change any reachable UI surface?

- [x] No UI surface impact
- [ ] Existing page changed
- [ ] New page/route added
- [ ] Navigation changed
- [ ] Filament panel/provider surface changed
- [ ] New modal/drawer/wizard/action added
- [ ] New table/form/state added
- [ ] Customer-facing surface changed
- [ ] Dangerous action changed
- [ ] Status/evidence/review presentation changed
- [ ] Workspace/environment context presentation changed

No-impact rationale: Spec 429 is a catalog and adapter strategy package. It must not edit runtime UI files, route files, Filament resources/pages/widgets, navigation, reports, downloads, customer outputs, or browser-rendered diagnostics.

## UI/Productization Coverage *(mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write `N/A - no reachable UI surface impact` plus rationale)*

N/A - no reachable UI surface impact. Future specs that expose Exchange/Teams status, evidence, readiness, or adapter progress in rendered product surfaces must satisfy the Product Surface Contract before runtime UI edits.

## Product Surface Impact *(mandatory for UI-affecting specs; otherwise write `N/A - no rendered product surface changed` plus rationale)*

Reference: `docs/product/standards/product-surface-contract.md`.

- **Product Surface Contract applies?**: no - no rendered product surface changes.
- **Page archetype**: N/A.
- **Primary user question**: N/A.
- **Primary action**: N/A.
- **Surface budget result**: N/A.
- **Technical Annex / deep-link demotion**: N/A for runtime. Catalog artifacts may discuss technical source surfaces, but no OperationRun, evidence, raw payload, ID, source key, detector, fingerprint, or log is rendered in the application.
- **Canonical status vocabulary**: N/A for UI. Documentation-only catalog status values are not runtime status vocabulary.
- **Visible complexity impact**: neutral in runtime; future implementation should decrease hidden Exchange/Teams ambiguity.
- **Product Surface exceptions**: none.

## Browser Verification Plan *(mandatory)*

- **Browser proof required?**: no.
- **No-browser rationale**: `N/A - no rendered UI surface changed`.
- **Focused path when required**: N/A.
- **Primary interaction to execute**: N/A.
- **Console, Livewire, Filament, network, and 500-error checks**: N/A.
- **Full-suite failure triage**: N/A.

## Human Product Sanity Check *(mandatory)*

- **Required?**: no.
- **No-human-sanity rationale**: N/A - no product surface changed.
- **Reviewer questions**: N/A for runtime. Manual artifact review should verify the catalog is actionable, does not imply readiness, and keeps source boundaries clear.
- **Planned result location**: future implementation report.

## Product Surface Merge Gate Checklist *(mandatory)*

- [x] No-legacy posture or approved exception recorded.
- [x] Product Surface Impact is completed or `N/A` is justified.
- [x] Browser proof is completed or `N/A - no rendered UI surface changed` is justified.
- [x] Human Product Sanity is completed or not applicable with rationale.
- [x] Product Surface exceptions are documented or `none`.
- [x] Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, no completed-spec rewrite assertion, and no application implementation.

## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*

- **Cross-cutting feature?**: no runtime touch; yes as planning context for future source/evidence surfaces.
- **Interaction class(es)**: N/A for runtime.
- **Systems touched**: Spec artifacts only. Read-only references include Coverage v2 registry/source-contract/identity/claim guard truth and completed Exchange/Teams helper specs.
- **Existing pattern(s) to extend**: none in this spec. Future implementation must reuse Coverage v2 source-contract, generic capture/evidence, canonical identity, OperationRun, Claim Guard, and product-surface patterns.
- **Shared contract / presenter / builder / renderer to reuse**: N/A now; later specs must name exact repo classes before runtime work.
- **Why the existing shared path is sufficient or insufficient**: Existing Coverage v2 paths are sufficient for proof and claims, but insufficient for Exchange/Teams capture because no source adapters/contracts exist for the first target types.
- **Allowed deviation and why**: static catalog documentation only.
- **Consistency impact**: Later runtime work must not create a parallel Exchange/Teams product language, evidence path, or customer claim path.
- **Review focus**: Confirm the catalog maps future work back to existing shared paths rather than inventing an Exchange/Teams mini-platform.

## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*

- **Touches OperationRun start/completion/link UX?**: no.
- **Shared OperationRun UX contract/layer reused**: N/A.
- **Delegated start/completion UX behaviors**: N/A.
- **Local surface-owned behavior that remains**: none.
- **Queued DB-notification policy**: N/A.
- **Terminal notification path**: N/A.
- **Exception required?**: none.

Any future adapter/capture implementation that performs remote work must create/reuse canonical OperationRun semantics through existing shared paths before provider execution.

## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*

- **Shared provider/platform boundary touched?**: yes, as documentation-only classification.
- **Boundary classification**: mixed. Coverage v2 source-contract, evidence, identity, claim, scope, and customer-output gates are platform-core. Exchange Online, Teams, Security & Compliance, Graph, Admin API, PowerShell cmdlets, provider-native IDs, permission names, and response shapes are provider-owned source details.
- **Seams affected**: Spec/catalog artifacts only; no runtime seam changes.
- **Neutral platform terms preserved or introduced**: workspace, managed environment, provider connection, target type, source surface, source contract candidate, adapter pattern, evidence state, claim boundary, blocker.
- **Provider-specific semantics retained and why**: Exchange/Teams family names, Microsoft cmdlet/API names, and Microsoft permission/RBAC terms are retained only as provider-owned source research needed to select future adapters.
- **Why this does not deepen provider coupling accidentally**: No provider-specific table, runtime registry, route, UI, OperationRun type, adapter, endpoint, permission, or customer claim is added.
- **Follow-up path**: document-in-feature now; Spec 430 must separately justify any runtime adapter and provider permission work.

## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*

N/A - no operator-facing surface change.

## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: no runtime source of truth. The future catalog artifacts are planning truth only.
- **New persisted entity/table/artifact?**: no runtime persisted entity/table. The implementation loop will create static Spec Kit catalog documents.
- **New abstraction?**: no runtime abstraction.
- **New enum/state/reason family?**: no runtime enum or persisted status family. Catalog status/source/adapter values are documentation-only vocabulary.
- **New cross-domain UI framework/taxonomy?**: no UI framework. Documentation-only target type taxonomy is introduced to prevent unsafe adapter work.
- **Current operator problem**: Release reviewers cannot safely approve the next Exchange/Teams adapter/evidence step without knowing which source surfaces are safe, valuable, and bounded.
- **Existing structure is insufficient because**: The existing Coverage v2 path blocks capture correctly, but it does not answer which Exchange/Teams source surface should be implemented first or how to avoid one-off adapter drift.
- **Narrowest correct implementation**: Static catalog and strategy artifacts, no runtime machinery.
- **Ownership cost**: Maintaining catalog artifacts and carrying source-boundary decisions into later specs.
- **Alternative intentionally rejected**: Implementing four adapters directly, guessing Graph endpoints, using PowerShell one-offs, broad Exchange/Teams mini-platforms, and customer-readiness claims.
- **Release truth**: Current-release prerequisite truth for future adapter implementation.

### Compatibility posture

This feature assumes a pre-production environment. Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope.

## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*

- **Test purpose / classification**: docs/spec/catalog validation only; no runtime test family.
- **Validation lane(s)**: Spec Kit artifact validation plus static no-runtime checks.
- **Why this classification and these lanes are sufficient**: No application code, migrations, runtime config, UI, tests, provider calls, evidence, or OperationRuns are changed by the spec preparation. Later docs-only implementation should prove file existence and no-runtime diff.
- **New or expanded test families**: none.
- **Fixture / helper cost impact**: none.
- **Heavy-family visibility / justification**: none.
- **Special surface test profile**: N/A.
- **Standard-native relief or required special coverage**: `N/A - no rendered UI surface changed`.
- **Reviewer handoff**: Confirm changed files stay under the Spec 429 package, catalog artifacts are complete, and no app/runtime files are touched.
- **Budget / baseline / trend impact**: none.
- **Escalation needed**: none for prep; reject-or-split if runtime adapter work is attempted.
- **Active feature PR close-out entry**: Guardrail / Exception / Smoke Coverage: `N/A - catalog/strategy only, no rendered UI surface changed`.
- **Planned validation commands**:
  - `git status --short`
  - `git diff --check`
  - `git diff --name-only`
  - Optional if JSON catalog is added later: `python3 -m json.tool specs/429-exchange-teams-source-surface-catalog-adapter-strategy/catalog/exchange-teams-target-types.json > /dev/null`

## Source Reference Basis *(preparation notes)*

The implementation loop must use official Microsoft documentation and repo truth only. Initial official source anchors:

- [Exchange Online PowerShell](https://learn.microsoft.com/en-us/powershell/exchange/exchange-online-powershell?view=exchange-ps)
- [Exchange Online PowerShell app-only authentication](https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps)
- [Overview of the Exchange Online Admin API](https://learn.microsoft.com/en-us/exchange/reference/admin-api-overview)
- [Authentication and authorization for the Exchange Online Admin API](https://learn.microsoft.com/en-us/exchange/reference/admin-api-authentication)
- [Exchange PowerShell cmdlet module reference](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/?view=exchange-ps)
- [MicrosoftTeams PowerShell module reference](https://learn.microsoft.com/en-us/powershell/module/microsoftteams/?view=teams-ps)
- [Teams app permission policies](https://learn.microsoft.com/en-us/microsoftteams/teams-app-permission-policies)
- [Teams app setup policies](https://learn.microsoft.com/en-us/microsoftteams/teams-app-setup-policies)
- [Teams settings and policies reference](https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference)
- [Teams guest and external access](https://learn.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations)
- [Exchange mail flow rules](https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/manage-mail-flow-rules)
- [Exchange accepted domains](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains)
- [Exchange remote domains](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/remote-domains/remote-domains)
- [Microsoft Graph Teams overview](https://learn.microsoft.com/en-us/graph/api/resources/teams-api-overview?view=graph-rest-1.0)

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Catalog Source Surfaces Without Claims (Priority: P1)

As a release reviewer, I need Exchange and Teams administration families cataloged by source surface and adapter pattern so I can approve a later implementation sequence without confusing cataloged surfaces with supported evidence.

**Why this priority**: This is the core safety gate. Without it, later implementation may guess endpoints, over-select Cohort 1, or imply readiness.

**Independent Test**: Verify `exchange-source-surface-catalog.md`, `teams-source-surface-catalog.md`, and `exchange-teams-target-type-matrix.md` exist, cite official/repo sources, classify source surfaces and adapter patterns, and state no runtime support is created.

**Acceptance Scenarios**:

1. **Given** the Spec 429 package, **When** a reviewer opens the catalog artifacts, **Then** Exchange and Teams families are mapped to source surface classes and adapter patterns without runtime claims.
2. **Given** a target type lacks source or permission clarity, **When** the matrix is reviewed, **Then** the row is deferred, blocked, unsupported, or unknown rather than selected for Cohort 1.

---

### User Story 2 - Select a Bounded Core Cohort (Priority: P2)

As a future implementer, I need Cohort 1, Cohort 2, and deferred/backlog decisions so Spec 430 can implement the narrowest valuable adapter slice.

**Why this priority**: Adapter implementation must be small, reviewable, and product-relevant.

**Independent Test**: Verify `cohort-plan.md` selects approximately 12-20 Cohort 1 candidates or documents a scoped exception, includes both Exchange and Teams, excludes Purview/Defender/SharePoint boundary items unless justified, and records selection rationale.

**Acceptance Scenarios**:

1. **Given** candidate target types from Exchange and Teams, **When** Cohort 1 is selected, **Then** each selected type has identifiable source surface, adapter pattern, risk, complexity, and customer/MSP value.
2. **Given** a valuable but high-risk target type, **When** the cohort plan is reviewed, **Then** the type is placed in Cohort 2 or deferred with an explicit reason.

---

### User Story 3 - Produce an Actionable Adapter Strategy (Priority: P3)

As a future adapter implementer, I need the adapter strategy to separate Graph-native, Exchange Admin API, Exchange PowerShell, Teams PowerShell, Security & Compliance, unsupported, and unknown paths.

**Why this priority**: The first implementation spec after 429 must know which adapter path comes first and what security/product review it requires.

**Independent Test**: Verify `adapter-strategy.md` identifies adapter patterns, first implementation sequence, authentication and permission concerns, execution environment concerns, redaction/testability requirements, and no-runtime constraints.

**Acceptance Scenarios**:

1. **Given** a candidate requiring Exchange Online PowerShell, **When** the adapter strategy is reviewed, **Then** it documents auth options, tenant consent, execution environment, module dependency, error normalization, redaction, throttling, and fake command-runner testability.
2. **Given** a candidate covered by the Exchange Online Admin API, **When** the strategy is reviewed, **Then** it records the preview/focused-scope limitation and does not treat the API as a full Exchange Online PowerShell replacement.

### Edge Cases

- Official Microsoft documentation shows a setting is portal-only or unstable.
- A target type overlaps Exchange and Purview/Defender boundaries.
- A Teams policy overlaps SharePoint/OneDrive file governance.
- A source exists only in Graph beta or preview API.
- A source shape is a singleton tenant setting rather than a collection.
- A source depends on per-user/per-mailbox enumeration and would explode Cohort 1 scope.
- A source requires broad admin roles or app-only permissions that are not least-privilege enough for SaaS capture.
- A Microsoft cmdlet represents an operational action rather than durable configuration.

## Requirements *(mandatory)*

### Functional Requirements

- **FR-429-001**: The implementation MUST create `catalog/exchange-source-surface-catalog.md`.
- **FR-429-002**: The implementation MUST create `catalog/teams-source-surface-catalog.md`.
- **FR-429-003**: The implementation MUST create `catalog/exchange-teams-target-type-matrix.md`.
- **FR-429-004**: The implementation MUST create `catalog/cohort-plan.md`.
- **FR-429-005**: The implementation MUST create `catalog/adapter-strategy.md`.
- **FR-429-006**: The Exchange catalog MUST cover mail flow/transport, domains/connectors, organization configuration, sharing/relationship configuration, protection/hygiene boundary, recipient/mailbox boundary, and Purview/Security & Compliance boundary.
- **FR-429-007**: The Teams catalog MUST cover app governance, meetings/events, messaging/channels, calling/voice, external/guest access, and files/storage/integration boundary.
- **FR-429-008**: Every target type matrix row MUST include canonical type, human label, workload, admin area, source surface class, adapter pattern, source reference, expected object shape, singleton/collection classification, identity candidate, identity risk, permission risk, response shape risk, redaction risk, compare complexity, render complexity, customer value, MSP value, cohort, status, blocker reason, and notes.
- **FR-429-009**: Source surface class values MUST be documentation-only and limited to `graph_v1`, `graph_beta_experimental`, `exchange_online_powershell_rest`, `exchange_online_admin_api`, `teams_powershell`, `security_compliance_powershell`, `sharepoint_pnp_related`, `unsupported_manual_only`, and `unknown_requires_research`.
- **FR-429-010**: Adapter pattern values MUST be documentation-only and limited to `existing_graph_client_contract`, `new_graph_contract`, `new_exchange_admin_api_contract`, `new_exchange_powershell_adapter`, `new_teams_powershell_adapter`, `new_security_compliance_adapter`, `defer_to_purview_adapter`, and `unsupported`.
- **FR-429-011**: Status values MUST be documentation-only and limited to `cohort_1_candidate`, `cohort_1_selected`, `cohort_2_candidate`, `deferred`, `blocked_missing_source`, `blocked_permission_unclear`, `blocked_identity_unsafe`, `blocked_response_shape_unsafe`, `blocked_product_value_low`, `blocked_purview_boundary`, `unsupported`, and `unknown_requires_research`.
- **FR-429-012**: Risk values MUST be documentation-only and limited to `low`, `medium`, `high`, `critical`, and `unknown`.
- **FR-429-013**: Complexity values MUST be documentation-only and limited to `simple`, `moderate`, `complex`, `very_complex`, and `unknown`.
- **FR-429-014**: Cohort 1 MUST include both Exchange and Teams candidates and SHOULD contain 12-20 target types unless the catalog documents why fewer are safer.
- **FR-429-015**: Cohort 1 MUST exclude unsupported/manual-only, unknown, beta-only certification blockers, portal-only, primarily Purview/Defender, and primarily SharePoint/OneDrive types unless a documented exception explains why they are still safe.
- **FR-429-016**: The adapter strategy MUST state which adapter pattern should be implemented first in Spec 430 and why.
- **FR-429-017**: The adapter strategy MUST document PowerShell adapter concerns: authentication options, certificate/application auth feasibility, tenant consent, execution environment, module dependencies, throttling/rate limits, error normalization, response serialization, redaction, fake command runner testability, and no shell execution in unit tests.
- **FR-429-018**: The adapter strategy MUST document Graph contract concerns when applicable: endpoint/resource availability, v1/beta status, permissions, pagination, identity fields, response shape, redaction, and `GraphClientInterface` compatibility.
- **FR-429-019**: The adapter strategy MUST document Exchange Online Admin API concerns when applicable: preview status, supported scenarios, unsupported scenarios, permissions/RBAC, POST-only behavior, response shape, and why it is not a full Exchange Online PowerShell replacement.
- **FR-429-020**: The catalog MUST treat Microsoft cmdlets as source evidence, not automatic TenantPilot target types.
- **FR-429-021**: The catalog MUST preserve the current repo truth that `transportRule`, `acceptedDomain`, `appPermissionPolicy`, and `meetingPolicy` remain blocked by missing repo adapter/source contract until a later implementation spec changes that truth.
- **FR-429-022**: The implementation report MUST include target type summary, Cohort 1, adapter strategy, and no-promotion matrices.
- **FR-429-023**: The implementation MUST NOT change files outside `specs/429-exchange-teams-source-surface-catalog-adapter-strategy/` unless the spec is amended before work continues.
- **FR-429-024**: The implementation MUST NOT create or modify application runtime code, migrations, models, services, jobs, commands, policies, routes, views, Filament/Livewire UI, tests, provider clients, runtime config consumed by the app, database rows, evidence rows, or OperationRuns.
- **FR-429-025**: The implementation MUST NOT make or enable claims that Exchange/Teams are evidence-ready, content-backed, comparable, renderable, certified, restore-ready, customer-ready, full M365 ready, or pilot-ready.
- **FR-429-026**: The implementation MUST review and, if needed, update `checklists/requirements.md` after catalog artifacts and the implementation report are complete; the preparation PASS alone MUST NOT be treated as catalog implementation completion.

### Key Entities *(include if feature involves data)*

- **Catalog target type**: Documentation-only representation of a productized configuration resource candidate that may later become identifiable, captured, hashed, compared, rendered, claim-guarded, or certified.
- **Source surface class**: Documentation-only classification of where the source data appears to live: Graph, Exchange Online PowerShell, Exchange Online Admin API, Teams PowerShell, Security & Compliance PowerShell, SharePoint/PnP boundary, unsupported/manual, or unknown.
- **Adapter pattern**: Documentation-only classification of the future implementation pattern required to capture the target type safely.
- **Cohort**: Documentation-only grouping that controls implementation sequencing; it does not change runtime support.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-429-001**: A reviewer can identify Cohort 1 target types, source surfaces, adapter patterns, and major blocker reasons from the catalog artifacts without opening application source code.
- **SC-429-002**: Every Cohort 1 target type has non-empty source surface, adapter pattern, identity risk, permission risk, compare/render complexity, and customer/MSP value fields.
- **SC-429-003**: The adapter strategy names the first implementation spec path and separates Graph, Exchange Admin API, Exchange PowerShell, Teams PowerShell, Security & Compliance, unsupported, and unknown decisions.
- **SC-429-004**: Validation proves changed files are limited to the Spec 429 package and that no runtime/UI/evidence/OperationRun/customer-claim files changed.
- **SC-429-005**: No open question blocks starting Spec 430 as a docs-to-runtime adapter implementation spec.

## Assumptions

- Spec 428's prepared fail-safe/no-op status is non-blocking because Spec 429 is catalog-only and does not depend on evidence from Spec 428.
- Official Microsoft Learn pages and current repo source/test/spec truth are sufficient for source-surface classification.
- Catalog status/source/adapter values remain documentation vocabulary until a later spec explicitly promotes any value into runtime code with proportionality review.
- The first later implementation spec will be Spec 430 and will remain narrower than the full catalog.

## Open Questions

- None blocking for preparation. During implementation, official Microsoft source review may mark additional target types as unknown, unsupported, or deferred.

## Risks

| Risk | Severity | Mitigation |
| --- | ---: | --- |
| Catalog is mistaken for support/readiness | High | No-claim matrix and explicit no-runtime wording in every artifact |
| Cohort 1 becomes too broad | High | 12-20 target guidance, risk/value scoring, deferred backlog |
| Graph availability is overestimated | High | Official source reference required; beta/preview paths blocked from certification |
| PowerShell adapter complexity is underestimated | High | Separate adapter strategy and Spec 430 implementation gate |
| Purview/Defender/SharePoint boundaries blur | High | Boundary classification in catalog and deferred backlog |
| Runtime implementation sneaks in | High | Tasks and validation forbid app/runtime file changes |
| `tenant_id` returns | High | No-runtime/no-tenant-id proof in implementation report |

## Follow-up Spec Candidates

- Spec 430 - Exchange/Teams Adapter Cohort 1 Implementation.
- Spec 431 - Exchange/Teams Content-Backed Evidence Promotion.
- Spec 432 - Exchange/Teams Comparable / Renderable Promotion.
- Spec 433 - Exchange/Teams Certified Core Compare Pack.
- Spec 434 - M365 Customer Output & Claim Guard.
- Spec 435 - M365 Pilot Readiness Gate.
- Purview/Security & Compliance adapter strategy if catalog boundaries show enough current-release value.
- SharePoint/OneDrive file governance source-surface catalog if Teams file/storage boundaries require it.