docs(teams): propose response lifecycle decisions

[NeoHsu]

Important

Stacked draft: logical base docs/teams-adr-delivery-trust is PR #1487. GitHub requires an upstream PR base to exist in openabdev/openab, so this draft temporarily targets main and may show preceding stack layers. Do not merge it until #1487 is merged and this branch is rebased onto current main; then review only its single incremental commit.

What problem does this solve?

Define durable response-lifecycle and content-delivery boundaries for Teams without coupling them to one tenant or rollout.

Discord Discussion URL: https://discord.com/channels/1491295327620169908/1491365158868619404/1531339032527765655
Microsoft Teams roadmap discussion.

Review Contract

Goal

Define durable response-lifecycle and content-delivery boundaries for Teams without coupling them to one tenant or rollout.

Non-goals

No runtime behavior, attachment download, platform write, deployment setting, or current acceptance claim is introduced.

Accepted Residual Risks

Visible placeholders or partial prefixes can remain after ambiguous platform outcomes; richer files/cards and cross-client presentation are deferred rather than implied.

Acceptance Criteria

The four ADRs state fail-closed admission, no-blind-retry behavior, bounded content handling, consequences, alternatives, and stable acceptance invariants with valid metadata and links.

Follow-ups

Implement processing, progressive response, attachment, and formatting slices independently so each can be reviewed and rolled out separately.

At a Glance

N/A — this PR changes documentation only; it introduces no runtime flow.

Prior Art & Industry Research

Not applicable — this is a documentation-only decision or guidance slice. The ADRs and guides cite the authoritative Microsoft and repository sources used for their claims.

Proposed Solution

• Add four Proposed ADRs for processing indicators, progressive responses, attachment ingress, and formatting/long-message delivery.
• Specify ambiguity handling, cleanup boundaries, metadata-first attachment admission, and exact message budgeting.
• Keep executable validation plans and tenant observations out of ADR text.

Why this approach?

Separating durable ADRs from mutable guides and evidence keeps architecture review stable while allowing operational status to evolve.

Alternatives Considered

Embed implementation chronology and tenant evidence in ADRs (rejected: it becomes stale) or publish no routing guide (rejected: operators cannot discover the supported path).

Validation

• git diff --check
• Relative Markdown link and form audit
• ADR metadata and mutable-section guards