feat: add portable forge-infra/v0 contract

CHANGELOG.md

@@ -7,6 +7,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Added
+
+- **Portable Forge Infrastructure Contract (draft).** Add the
+  `forge-infra/v0` seven-lane contract, canonical capability catalog,
+  evidence-backed provider and authority profiles, digest-bound binding plans,
+  non-secret transition receipts, time-bounded verification receipts, object
+  references, examples, rejects, and cross-document controls.
+- **ADR-0009: forge infrastructure contract.** Record the separation of
+  neutral forge capabilities, provider-native mappings, authority control, and
+  live assurance.
+- **Forge-infra reader guide.** Add a mechanics companion covering the
+  information model, seven lanes, and sibling-contract boundaries.
+
 ## [0.1.29] - 2026-08-24
 
 ### Added

Makefile

@@ -326,6 +326,8 @@ lint-config: lint-role-prompts lint-coverage-attestation ## Validate config data
 		sh scripts/test-service-job-controls.sh || exit 1; \
 		echo "    Project-work controls..."; \
 		sh scripts/test-project-work-controls.sh || exit 1; \
+		echo "    Forge-infra controls..."; \
+		sh scripts/test-forge-infra-controls.sh || exit 1; \
 		echo "    Validating contract manifests..."; \
 		sh scripts/validate-contract-manifests.sh \
 			schemas/data-artifact/v0/contract.json \
@@ -334,7 +336,8 @@ lint-config: lint-role-prompts lint-coverage-attestation ## Validate config data
 			schemas/review-journal/v0/contract.json \
 			schemas/agent-wait/v0/contract.json \
 			schemas/service-job/v0/contract.json \
-			schemas/project-work/v0/contract.json || exit 1; \
+			schemas/project-work/v0/contract.json \
+			schemas/forge-infra/v0/contract.json || exit 1; \
 	else \
 		echo "[!!] goneat not found, skipping config validation"; \
 	fi

README.md

@@ -110,6 +110,7 @@ This is a **reference-based model**—we don't sync standards into repositories.
 │   ├── coverage-attestation/v0/  # Coverage attestation (proposed)
 │   ├── agent-wait/v0/         # Portable agent wait/poll contract
 │   ├── data-artifact/v0/      # Portable data artifact contract
+│   ├── forge-infra/v0/        # Forge capabilities, provider profiles, authority bindings
 │   ├── foundation/v0/         # Lifecycle phases, release phases, types
 │   ├── process-run/v0/        # Local process telemetry/control (proposed)
 │   ├── project-work/v0/       # Ready packets, project state, work ledger (draft)

docs/README.md

@@ -42,6 +42,7 @@ Run-books and adoption guides — the mechanics companion to the standards.
 
 - [running-a-fierce-collaboration-review.md](guides/running-a-fierce-collaboration-review.md) - Executable steps for the fierce-collaboration review standard
 - [composing-a-review-panel.md](guides/composing-a-review-panel.md) - Assembling review seats and panels: the five-layer composition model, harness classes, framing blocks, and preflight
+- [using-the-forge-infrastructure-contract.md](guides/using-the-forge-infrastructure-contract.md) - Reader tour of `forge-infra/v0`: information model, seven lanes, and sibling contracts
 - [agentic-interface-adoption.md](guides/agentic-interface-adoption.md) - Adopting the role catalog and attribution baseline
 - [multi-org-github-cli-auth.md](guides/multi-org-github-cli-auth.md) - GitHub CLI auth across orgs
 
@@ -59,6 +60,7 @@ Cross-cutting classification standards for data and artifacts, plus contract sta
 - [agent-wait-contract.md](standards/agent-wait-contract.md) - Portable wait/poll contract for one aggregate waiter per consuming seat
 - [classifiers-framework.md](standards/classifiers-framework.md) - How the classifiers system fits together (docs + config + schemas)
 - [data-artifact-contract.md](standards/data-artifact-contract.md) - Portable artifact, representation, catalog, provenance, and protection contract
+- [forge-infrastructure-contract.md](standards/forge-infrastructure-contract.md) - Seven-lane forge capability, authority, resolution, and assurance contract
 - [service-job-contract.md](standards/service-job-contract.md) - Portable catalog, digest-bound submit, and job lifecycle contract
 - [project-work-contract.md](standards/project-work-contract.md) - Portable ready-packet, project-state, control-record, and progress-ledger contract
 - [data-artifact-contract-examples.md](standards/data-artifact-contract-examples.md) - Source-neutral stress cases and producer adoption preview template
@@ -81,6 +83,8 @@ Decision and governance records (ADR / PDR / …) — see the [decisions index](
 - [ADR-0001](decisions/ADR-0001-schema-config-versioning.md) - Schema and config versioning
 - [ADR-0002](decisions/ADR-0002-keymaterial-fingerprint-portable-contract.md) - Key-material fingerprint contract as a portable schema (proposed)
 - [ADR-0003](decisions/ADR-0003-decision-record-taxonomy.md) - Decision & governance record taxonomy (the \*DR family)
+- [ADR-0008](decisions/ADR-0008-project-work-contract.md) - Portable project-work companion contract (proposed)
+- [ADR-0009](decisions/ADR-0009-forge-infrastructure-contract.md) - Neutral forge capabilities and curated provider profiles (proposed)
 - [PDR-0001](decisions/PDR-0001-adopt-data-pipeline-principles.md) - Adopt the data-pipeline engineering principles
 
 ### [Catalog](catalog/)
@@ -122,6 +126,8 @@ Current release documentation.
 | CI/CD Baseline           | `crucible.3leaps.dev/operations/ci-baseline`                              |
 | Stream Output            | `crucible.3leaps.dev/sop/stream-output`                                   |
 | Auth Session Artifact    | `crucible.3leaps.dev/standards/auth-session-artifact`                     |
+| Forge Infrastructure     | `crucible.3leaps.dev/standards/forge-infrastructure-contract`             |
+| Using Forge Infra        | `crucible.3leaps.dev/guides/using-the-forge-infrastructure-contract`      |
 | Data Sensitivity         | `crucible.3leaps.dev/standards/data-sensitivity-classification`           |
 | Classifiers Framework    | `crucible.3leaps.dev/standards/classifiers-framework`                     |
 | Volatility               | `crucible.3leaps.dev/standards/volatility-classification`                 |

docs/decisions/ADR-0009-forge-infrastructure-contract.md

@@ -0,0 +1,160 @@
+---
+id: "ADR-0009"
+title: "Separate Neutral Forge Capabilities from Curated Provider Profiles"
+status: "proposed"
+date: "2026-08-27"
+last_updated: "2026-08-27"
+deciders:
+  - "@3leapsdave"
+scope: "Crucible foundation / forge-infrastructure contracts"
+tags:
+  - "schemas"
+  - "forge"
+  - "authorization"
+  - "interchange-contract"
+relates-to:
+  - "crucible ADR-0001 (schema/config versioning)"
+  - "docs/standards/data-artifact-contract.md"
+  - "docs/standards/project-work-contract.md"
+---
+
+# ADR-0009: Separate Neutral Forge Capabilities from Curated Provider Profiles
+
+## Status
+
+**Current Status**: Proposed — the contract enters review at `v0`.
+
+## Context
+
+Git hosting providers expose useful infrastructure beyond repository storage:
+issues, automation, runners, statuses, checks, packages, releases, deployment
+governance, webhooks, and other event surfaces.
+
+The providers do not expose one shared feature or authorization model.
+Similarly named features differ by operation, principal, resource scope,
+grant vocabulary, offering, lifecycle, and event behavior. Application
+registration, user consent, installation, token issuance, and runner
+registration are distinct transitions.
+
+A single provider-by-feature matrix would either freeze the lowest common
+denominator or claim parity that does not exist. A provider-specific contract
+per implementation would prevent adopters from expressing portable
+requirements.
+
+## Decision
+
+Establish `contract: forge-infra/v0` with:
+
+1. L1 requirement profiles and digest-bound binding plans;
+2. L2 authority profiles, closed policy-input facts, and immutable non-secret
+   transition receipts;
+3. an explicit L3–L6 neutral capability catalog for native git, forge
+   resources, automation, events, and telemetry;
+4. curated provider profiles mapping native features and authority profiles
+   onto that catalog with dated evidence;
+5. L7 time-bounded verification receipts for live conformance and drift; and
+6. stable forge-object references that exclude access context.
+
+`contract.json` is the schema-registry entry point and exposes the canonical
+catalog plus all public object schemas. The catalog is a versioned artifact,
+not an illustrative example.
+
+### Operation and authority are the support key
+
+Provider profiles make availability claims per neutral operation and authority
+profile. A feature-level boolean is insufficient. The same provider-native
+feature may be available to a user token and unavailable to an application
+installation.
+
+### Provider vocabulary remains visible
+
+Permission, scope, role, feature, and offering names remain provider-native
+data in provider profiles. Neutral capability ids describe jobs and operations
+without renaming vendor grants into a fictitious common permission model.
+
+### Consumer policy is an overlay
+
+Information stores, revision stores, long-running agent memory, and other
+adopters express requirements against the neutral catalog. Their preferred or
+forbidden uses do not become provider facts.
+
+### Evidence is part of a claim
+
+Provider profiles carry observation times and source references. Unknown or
+stale evidence does not become support by inference.
+
+### Receipts are non-secret
+
+Binding receipts carry public identifiers and grant names. Credential material
+remains outside the contract. Registering an application does not by itself
+prove that an authorized principal or usable token exists.
+
+### Binding and verification are distinct
+
+A binding receipt proves that one controlled transition was attempted. It does
+not prove current authority. Verification receipts are time-bounded and report
+expected, observed, missing, and unexpected grants plus capability checks.
+Receipts cite a specific digest-bound plan action; successor transitions cite a
+successful predecessor so failed work cannot advance the authority chain.
+
+### Provider and instance identity are extensible
+
+Provider identity is not a closed vendor enum. A shared provider context
+distinguishes hosted, self-managed, dedicated, and other instance or offering
+contexts.
+
+### Events separate subscription from delivery
+
+Subscription management is a forge capability. Delivery envelopes, retry,
+acknowledgement, signature verification, and local receiver execution remain
+the responsibility of their respective contracts and integrations.
+
+## Consequences
+
+- Adopters can compare providers without erasing meaningful differences.
+- Provider profiles can evolve independently of the neutral vocabulary.
+- Authority acquisition and capability use remain connected without becoming
+  one credential blob.
+- Provider-native limitations and feature names remain representable without
+  turning arbitrary extension keys into portable contract vocabulary.
+- Cross-document validation is required in addition to JSON Schema.
+- Curated provider profiles require ongoing evidence refresh.
+- Implementations need a resolver rather than a one-row feature lookup.
+- Side-effecting authority operations need digest and idempotency binding.
+- Consumers need explicit verification and reconciliation policies.
+
+## Alternatives considered
+
+### One common provider API
+
+Rejected. It would either omit high-value provider capabilities or give
+similarly named operations misleadingly identical semantics.
+
+### One provider-by-feature boolean matrix
+
+Rejected. Availability depends on operation, authority, resource scope,
+offering, and grants.
+
+### Provider-specific contracts only
+
+Rejected. Adopters could not state portable requirements or evaluate fallback
+paths.
+
+### Combine application registration and granted authority
+
+Rejected. Registration, installation, consent, and token issuance have
+different principals, outputs, and security boundaries.
+
+### Put adopter use cases in provider rows
+
+Rejected. A provider fact should not change when an information store or
+revision store changes policy.
+
+## Review-loop items
+
+1. Whether the canonical neutral catalog should later publish on a separate
+   registry release cadence from provider profiles.
+2. Whether provider profiles need signed provenance or freshness policy
+   metadata beyond source URI and observation time.
+3. Whether a later companion contract should normalize webhook delivery and
+   retry semantics.

docs/decisions/README.md

@@ -51,6 +51,7 @@ Examples:
 | [ADR-0006](ADR-0006-process-run-contract.md)                               | Local Process Telemetry & Control as a Companion Portable Contract | proposed | 2026-07-06 |
 | [ADR-0007](ADR-0007-separate-documentation-and-schema-registry-origins.md) | Separate Crucible Documentation and Schema Registry Origins        | proposed | 2026-08-19 |
 | [ADR-0008](ADR-0008-project-work-contract.md)                              | Portable Project Work as a Companion Contract                      | proposed | 2026-08-21 |
+| [ADR-0009](ADR-0009-forge-infrastructure-contract.md)                      | Separate Neutral Forge Capabilities from Curated Provider Profiles | proposed | 2026-08-27 |
 | [PDR-0001](PDR-0001-adopt-data-pipeline-principles.md)                     | Adopt the Data-Pipeline Engineering Principles                     | accepted | 2026-06-29 |
 | [PDR-0002](PDR-0002-worktree-per-task.md)                                  | One git worktree per concurrent task                               | accepted | 2026-06-29 |
 | [PDR-0003](PDR-0003-role-portfolio-tiering.md)                             | Role portfolio tiering: core, supplemental, deprecated             | accepted | 2026-06-29 |