docs(teams): propose commands and proactive delivery

[NeoHsu]

Important

Stacked draft: logical base docs/teams-adr-response-content is PR #1488. 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 #1488 is merged and this branch is rebased onto current main; then review only its single incremental commit.

What problem does this solve?

Define command admission, persistent route authority, and proactive operator scheduling before those capabilities are implemented.

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

Review Contract

Goal

Define command admission, persistent route authority, and proactive operator scheduling before those capabilities are implemented.

Non-goals

No command execution, filesystem registry, proactive send, cron target, live evidence, or tenant configuration is added.

Accepted Residual Risks

The registry design accepts single-writer filesystem limits, while proactive delivery is limited to operator baseline jobs and exact trusted routes.

Acceptance Criteria

The ADRs keep secrets and service URLs Gateway-local, make command admission precede side effects, require explicit registry opt-in, reject usercron Teams authority, and retain Proposed metadata with valid links.

Follow-ups

Land text commands, registry persistence, and operator cron as separate implementation PRs; design user-created reminders under a separate authority contract.

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 Proposed ADRs for text commands, the trusted persistent conversation registry, and operator-owned Teams cron delivery.
• Clarify that persistent route authority stays Gateway-local and agent-writable schedules cannot inherit it.
• Update the historical Custom Gateway ADR without adding a project-specific ADR index.

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