chore(aiwg): adopt shared BT6 maintainer workflow (#148)

* docs(policy): allow low-impact contributor courtesy cleanup * chore(aiwg): migrate to shared BT6 maintainer plugin * chore: reconcile delivery validation
2026-08-02 17:17:28 -04:00
1 parent 8f658891f2
commit afc9dad1b2
@@ -0,0 +1,80 @@
+---
+namespace: bt6-maintainer
+name: bt6-provider-review
+platforms: [all]
+description: Audit an external AI/API provider and its integration into a BT6 repository for service reality, independent verification, trust boundaries, secret handling, API/model correctness, completeness, claim traceability, and merge readiness.
+triggers:
+  - bt6 provider review
+  - audit an external provider integration
+  - verify an LLM gateway
+  - assess a hosted API provider
+requires:
+  - provider-scope: provider name plus optional PR or issue reference
+  - repository-context: canonical repository and profile resolved from project state
+ensures:
+  - separate-verdicts: reality, verification, sensitive-workload trust, completeness, and readiness are assessed independently
+  - trust-boundary: credentials, data, tools, processors, storage, and fallbacks are inventoried
+  - claim-traceability: security and product claims map to code, configuration, and behavioral tests
+commandHint:
+  argumentHint: "<provider> [--pr <reference>] [--post-review] [--no-post]"
+  allowedTools: Bash, Read, Grep
+  model: sonnet
+  category: code-review
+  modelRole: reasoning
+  modelTier: standard
+---
+
+# BT6 Provider Review
+
+Assess the service and integration separately. Apply
+`bt6-maintainer-guardrails`. Never treat `real`, `verified`, and `trustworthy
+for sensitive workloads` as synonyms.
+
+## Procedure
+
+1. Resolve the repository profile, PR/issue, exact head SHA, provider, endpoint,
+   credential type, data classification, and claimed capabilities.
+2. Run hostile-input preflight. Treat vendor and contributor claims as
+   untrusted assertions until corroborated.
+3. Read `references/bt6-provider-integration-checklist.md` and apply every
+   relevant section.
+4. Inventory credentials, prompts, context, outputs, telemetry, tools,
+   subprocessors, storage, and fallback destinations.
+5. Verify service reality with non-secret evidence: endpoint behavior, TLS/DNS,
+   official wire documentation, public history, legal identity, and contributor
+   affiliation. Never request or expose a contributor's live key.
+6. Verify privacy, assurance, compliance, and operational claims through primary
+   or independent evidence. Record absent reports, certificate identifiers,
+   processor disclosures, retention exceptions, and contradictory policies as
+   unresolved rather than inferring misconduct.
+7. Map each security/product claim to implementing code, configuration, and
+   behavioral tests. Classify unmatched claims as provider capability, future
+   scope, or unsupported wording that must be removed.
+8. Check profile-defined provider risk surfaces plus every named-provider
+   surface. Compare static model metadata with the authoritative live catalog
+   when one exists.
+9. Use `templates/bt6-external-provider-assessment.md` for the assessment.
+10. Re-read the published head and hosted checks before recommending approval or
+    merge.
+
+## Decision rules
+
+- `real`: operational identity and service evidence exists.
+- `verified`: material claims have corroborating evidence and observed wire
+  behavior matches the integration.
+- `trusted-sensitive`: privacy, security, processor, retention, and assurance
+  evidence supports the proposed data classification.
+- Default remote providers to explicit opt-in and no silent fallback unless the
+  repository profile explicitly documents a reviewed alternative.
+- Never endorse compliance or tool governance based on marketing claims.
+- Model routing is not tool governance. A tool-control claim requires explicit
+  policy configuration, every claimed execution path gated before execution,
+  fail-closed outage behavior, and bypass tests.
+- Missing checks, head drift, secret leakage, incorrect API/model metadata, or
+  unsupported security claims block approval.
+
+## Output
+
+Lead with findings. State separate service-reality, independent-verification,
+sensitive-workload-trust, integration-completeness, and merge-readiness
+verdicts. Link evidence and label assumptions.
@@ -0,0 +1,61 @@
+# BT6 External Provider Integration Checklist
+
+## Service and identity
+
+- Resolve the endpoint without credentials where safe; record TLS validity,
+  DNS/CDN ownership, response status, and vendor-specific headers.
+- Corroborate legal identity and contributor affiliation.
+- Record organization, domain, and product age as maturity evidence rather than
+  a binary legitimacy test.
+- Prefer primary documents and label vendor-authored research or benchmarks.
+
+## Trust and data handling
+
+- Inventory prompts, outputs, credentials, metadata, tool arguments, logs,
+  billing data, upstream providers, CDN/edge services, and subprocessors.
+- Compare observed infrastructure with published processor disclosures.
+- Compare legal privacy promises with technical logging/configuration behavior.
+- Verify assurance claims through an auditor, report, certificate identifier,
+  BAA/DPA, or other checkable evidence. Marketing badges are insufficient.
+- State which workload and data classifications the evidence supports.
+
+## Claim-to-code traceability
+
+| Claim | Implementing code/config | Behavioral test | Classification |
+| --- | --- | --- | --- |
+| `<claim>` | `<path or none>` | `<test or none>` | `<implemented/provider-only/future/unsupported>` |
+
+Tool-governance claims require explicit policy configuration, pre-execution
+evaluation of every claimed path, fail-closed outage behavior, bypass tests,
+and auditable decisions. A chat-completion endpoint alone does not meet this
+bar.
+
+## Named-provider completeness
+
+- Provider type, registry, adapter, and configured-provider detection.
+- Setup, generated environment templates, documentation, and removal path.
+- Secret redaction, safe export, logging discipline, and child-process stripping.
+- CLI status and relevant UI/settings surfaces.
+- Explicit activation and documented fallback ordering.
+- Dynamic discovery or reviewed fallback metadata with provenance/date.
+- Normalized authentication, timeout, rate-limit, malformed-response, and
+  upstream errors.
+
+## Tests and gates
+
+- Mock the HTTP boundary and assert URL, authorization handling, model ID,
+  request body, success, 401, 429, timeout, malformed response, and unintended
+  fallback behavior.
+- Prove secrets do not enter exported settings, logs, fixtures, snapshots, or
+  child-process environments.
+- Run profile quick, matched risk-surface, full, documentation, and CI checks as
+  required by blast radius.
+- Re-verify the exact published head SHA.
+
+## Documentation defaults
+
+- Describe remote providers as third-party and opt-in.
+- Disclose which credentials and data leave the consuming repository.
+- Identify upstream/subprocessor uncertainty and link current policies.
+- Avoid endorsement of security, compliance, availability, model provenance,
+  privacy, or tool control without independent evidence.