docs(requirements): reconcile v2 product baseline

[hcoona]

Summary

Reconcile the accepted v2 requirements against the repository-owner use case, accepted
repository authorities, and the bounded public upstream source set in #14.

The 33 behavioral requirements accepted at the start of #14 were all reviewed, and the
nonbehavioral V2-REQ-050 reservation was preserved. This change:

• adds V2-REQ-017 for caller-intent precedence;
• clarifies V2-REQ-016 for interactive-surface ownership and completion;
• corrects V2-REQ-023 terminal fallback behavior;
• clarifies V2-REQ-030 typed-result and process-exit consistency;
• clarifies V2-REQ-040 explicit cache policy and mode authority;
• adds conditional V2-REQ-045 for headless-Linux reusable-state support claims; and
• adds matching scenarios to the existing validation strategy.

The proposed baseline has 35 behavioral requirements plus reserved V2-REQ-050.

Governing Record

• Accepted project state:
  main-v2@c939a561869da9505186b827c5244e6e9d1d994e
• Active work item:
  #14 — Reconcile and Baseline the V2 Product Requirements
• Milestone:
  Phase 1 — Empirical Baseline

Scope and Non-Goals

This pull request changes only existing capability-scoped requirement records and the
validation strategy that consumes them.

It does not freeze a request, result, or exit-code schema; select architecture,
mechanisms, cache modes, plaintext persistence, or platform support; run an experiment;
implement v2; activate #12; change compatibility or release commitments; modify upstream
source; or expand the authentication engine into Git, credential-provider, installer,
package-channel, or Azure DevOps PAT behavior.

Record-System Impact

• Changed families: product-requirements, validation-strategy
• Added behavioral requirement IDs: V2-REQ-017, V2-REQ-045
• Clarified existing IDs: V2-REQ-016, V2-REQ-023, V2-REQ-030, V2-REQ-040
• Preserved reservation: V2-REQ-050
• Added record families, schemas, controls, portals, or duplicate requirement
  authorities: None

The six capability files remain the sole product-requirement authority. The working
source reconciliation is not committed as a second specification.

Evidence and Reasoning

Source Reconciliation

Public sources were accessed on 2026-09-02. The six fixed capability searches in #14
returned 71 raw hits across seven transport batches. GitHub's Search API rejected the
eight-term strategy query because one query may contain no more than five Boolean
operators, so that unchanged term group was transported in two batches and unioned by
canonical URL. The strategy union contained 14 Issues; the six capability groups
contained 65 memberships and reduced to 29 unique Issues. Every response reported
incomplete_results: false. No recursive source, keyword, repository, author, label, or
organization expansion was performed.

The accepted audit and recheck registry also route to public
AzureAD#462. It was open and unmerged when accessed and
remains an implementation/evidence input governed by RECHECK-005, not a selected
requirement or architecture.

Original Use Case

• Strict multi-account selection is covered by V2-REQ-012, V2-REQ-020,
  V2-REQ-022, and V2-REQ-031.
• Silent-first and no-interaction behavior is covered by V2-REQ-013,
  V2-REQ-014, V2-REQ-020, V2-REQ-021, V2-REQ-025, and V2-REQ-032.
• Ordered WAM, browser, and device-code behavior remains expressible without selecting
  defaults or architecture.
• One deadline, cleanup, and concurrent-prompt coordination remain covered by
  V2-REQ-015, V2-REQ-025, and V2-REQ-026.
• Repository-to-account binding, Git helper routing, GCM behavior, and PAT fallback
  remain downstream consumer or product concerns under V2-REQ-002.
• Dependency canary and rollback needs remain covered by V2-REQ-052.

Public Upstream Disposition

Disposition	Public records	Result
Covered by existing requirements or the bounded clarifications in this change	AzureAD#24, AzureAD#56, AzureAD#133, AzureAD#174, AzureAD#398, AzureAD#408, AzureAD#410 reusable-state sub-need, AzureAD#436 browser-launch sub-need, AzureAD#455 hang sub-need, AzureAD#459, AzureAD#461, AzureAD#464, AzureAD#465	Account, interaction, host completion, deadline, typed failure, cache policy, dependency, and product-identity obligations are retained or clarified. AzureAD#410's proposed plaintext mode remains unaccepted.
Consumer or Azure DevOps PAT concern	AzureAD#71, AzureAD#229, AzureAD#422	Outside the delegated public-client authentication engine.
Implementation or architecture choice	AzureAD#47, AzureAD#114, AzureAD#454, AzureAD#455 default-order proposal, AzureAD#460, AzureAD#462	Does not become product policy in this change.
Distribution, installer, documentation, or release concern	AzureAD#46, AzureAD#121, AzureAD#129, AzureAD#166, AzureAD#326, AzureAD#335, AzureAD#350, AzureAD#410 .deb distribution sub-need, AzureAD#436 packaging sub-need, AzureAD#438, AzureAD#463	Existing compatibility, independent-identity, public-build, and real-platform authorities remain sufficient; no current release or channel is promised.

No unresolved public fact prevents a requirement disposition, so no follow-up research
Issue is created.

Repository-Owner Dispositions

The following product decisions are applied:

1. Explicit request fields override selected-profile defaults, which override permitted
   ambient defaults. Enforced profile and trust constraints cannot be overridden.
2. Interactive work requires a host context that identifies both the interactive-surface
   owner and completion channel.
3. Caller cancellation, user denial, strict identity mismatch, and failure to validate a
   reported success are terminal. Cache corruption remains a separate cache-lifecycle
   concern.
4. A normally emitted typed result and process exit status must map deterministically and
   cannot contradict one another; numeric codes remain undecided.
5. Cache persistence and fallback follow explicit policy composed only of separately
   owner-accepted modes. Request or profile input cannot authorize plaintext or another
   unaccepted mode.
6. Headless Linux support is not promised. If a combination later claims repeated
   noninteractive acquisition, it must demonstrate compliant cross-invocation
   authentication-state reuse or mark that capability unsupported.

These are technology-independent requirements. Contract and Architecture may encode
accepted policy but cannot select product-risk or support scope on its own.

Recheck Evaluation

No typed trigger fired:

• there is no contract-and-architecture stage entry or release for RECHECK-001 or
  RECHECK-002;
• no WSL, system-browser, or Linux-broker workstream is activated for RECHECK-003
  through RECHECK-005;
• no cache-design or client-profile decision is made for RECHECK-006 or
  RECHECK-007.

Mutable public Issues support source findings only. The accepted requirements are owner
decisions and do not claim that upstream has implemented the requested behavior.

Identity and Security Effects

There is no runtime identity, account, tenant, interaction, cache, host, client-ID,
telemetry, token, credential, or network operation.

The requirements prevent ambient inputs from silently widening caller intent and prevent
request/profile input from authorizing an unaccepted cache mode. They do not accept
plaintext persistence, claim a secure-store implementation, or claim headless-Linux
support.

No private downstream link, identity, quotation, count, organization-specific claim, or
unpublished observation appears in the change or this carrier.

Validation

• git diff --check
• requirement-identifier and record-family path checks
• mise run check
• staged .git/hooks/pre-commit
• all 32 public-build runner conformance groups

One initial full check observed an unchanged timing fixture report global
source-integrity failure before its expected mode-local timeout. The targeted conformance
retry and the complete check retry both passed; no public-build record or harness changed.

Review and Disposition

Final staged diff SHA-256:
625c2abc72e13f078cc7b33394fd1a480e55d4fb01ff3fafe436fbed4b5c87b7

Review	Independent reviewer	Result
Data and product requirements	requirements-baseline-data-review-final	No material findings.
Research evidence	requirements-baseline-research-review-final	No material findings.
Record system	requirements-baseline-record-review-final	No material findings.
Minimality	requirements-baseline-minimality-review-final	No material findings.

Material findings and independent triage:

Finding	Independent triage	Disposition
Discovery count conflated raw transport hits and capability memberships	requirements-reconciliation-count-triage: true positive, confidence 10	Recorded 71 raw hits, 14-item strategy union, 65 capability memberships, and 29 unique Issues separately.
AzureAD#436 browser launch and AzureAD#455 indefinite fallback were not explicitly mapped	requirements-reconciliation-browser-triage: true positive, confidence 10	Mapped to host completion, deadline, fallback, cleanup, and typed-failure requirements.
Unqualified integrity failure conflicted with recoverable cache corruption	requirements-reconciliation-integrity-triage: true positive, confidence 9	Terminal behavior now names failure to validate a reported success; V2-REQ-041 continues to own cache corruption.
AzureAD#410 reusable-state availability remained undispositioned	requirements-reconciliation-headless-triage: true positive, confidence 10	Owner accepted conditional V2-REQ-045; it does not promise headless-Linux support or select persistence architecture.
Explicit cache policy could implicitly authorize an undecided plaintext or other mode	requirements-baseline-cache-authority-triage: true positive, confidence 9	A request/profile may select only separately owner-accepted modes; future product policy, not contract design, accepts modes.
Validation treated ordinary default precedence as a rejected conflict	requirements-baseline-precedence-validation-triage: true positive, confidence 9	Normal request/profile/ambient differences now test override order; only enforced-profile or trust conflicts reject.
AzureAD#410 was classified wholly as covered despite distinct reusable-state, plaintext, and .deb sub-needs	requirements-pr-body-410-triage: true positive, confidence 9	The public-source table now splits reusable state from distribution and explicitly leaves plaintext unaccepted.
A carrier review reported that CAND-01 through CAND-06 lacked owner disposition	requirements-pr-body-owner-decision-triage: false positive, confidence 10	The owner separately accepted all six decisions after individual terminology and scenario review. Final public confirmation remains part of the separate merge gate.

Product and Record-System Gate: Pending explicit repository-owner approval. Do not
merge before that disposition is recorded.

Upstream Provenance

No upstream source was copied. Public source findings use AzureAuth at immutable commit
de20930c34b3b86c8a0ed7bbdeeca3f662dae918,
the public Issues listed above, and open PR
AzureAD#462 as accessed on 2026-09-02.

[hcoona]

Owner disposition — Product and Record-System Gate

Approved for merge by merge commit.

The product-requirement changes are limited to the six decisions accepted during #14. The validation-strategy changes are corresponding evidence gates; they do not add product behavior, support commitments, architecture, or implementation choices.

This disposition accepts the proposed 35 behavioral requirements and the V2-REQ-050 reservation as canonical after merge. It does not authorize architecture, implementation, #12, or any subsequent work.