Merge pull request #29 from tigrbl/codex/split-tigrcorn-into-packages

Add governed workspace package boundaries for Tigrcorn

Author: cobycloud

.dockerignore

@@ -0,0 +1,11 @@
+.git
+.venv
+.pytest_cache
+.tmp
+.uv-cache
+__pycache__
+*.py[cod]
+tmp*
+dist
+build
+*.egg-info

.github/workflows/_reusable-ci.yml

@@ -23,6 +23,22 @@ jobs:
           python-version: ${{ matrix.python-version }}
       - name: Upgrade pip
         run: python -m pip install --upgrade pip
+      - name: Install workspace packages
+        run: |
+          python -m pip install \
+            -e pkgs/tigrcorn-core \
+            -e pkgs/tigrcorn-config \
+            -e pkgs/tigrcorn-asgi \
+            -e pkgs/tigrcorn-contract \
+            -e pkgs/tigrcorn-transports \
+            -e pkgs/tigrcorn-protocols \
+            -e pkgs/tigrcorn-http \
+            -e pkgs/tigrcorn-security \
+            -e pkgs/tigrcorn-runtime \
+            -e pkgs/tigrcorn-static \
+            -e pkgs/tigrcorn-observability \
+            -e pkgs/tigrcorn-compat \
+            -e pkgs/tigrcorn-certification
       - name: Install project
         run: python -m pip install -e ".[certification,dev]"
       - name: Validate tree

.github/workflows/docs.yml

@@ -26,6 +26,22 @@ jobs:
         uses: actions/setup-python@42375524e23c412d93fb67b49958b491fce71c38
         with:
           python-version: "3.12"
+      - name: Install workspace packages
+        run: |
+          python -m pip install \
+            -e pkgs/tigrcorn-core \
+            -e pkgs/tigrcorn-config \
+            -e pkgs/tigrcorn-asgi \
+            -e pkgs/tigrcorn-contract \
+            -e pkgs/tigrcorn-transports \
+            -e pkgs/tigrcorn-protocols \
+            -e pkgs/tigrcorn-http \
+            -e pkgs/tigrcorn-security \
+            -e pkgs/tigrcorn-runtime \
+            -e pkgs/tigrcorn-static \
+            -e pkgs/tigrcorn-observability \
+            -e pkgs/tigrcorn-compat \
+            -e pkgs/tigrcorn-certification
       - name: Install project
         run: python -m pip install -e ".[certification,dev]"
       - name: Generate release automation pages

.github/workflows/phase9-certification-release.yml

@@ -1,4 +1,4 @@
-name: phase9-certification-release
+name: Release Certification
 
 on:
   workflow_dispatch:
@@ -15,7 +15,8 @@ on:
       - 'docs/review/conformance/state/CURRENT_REPOSITORY_STATE.md'
 
 jobs:
-  certification-environment-and-phase9-checkpoints:
+  certification-environment-and-release-checkpoints:
+    name: Certification Environment and Release Checkpoints (${{ matrix.python-version }})
     runs-on: ubuntu-latest
     environment: staging
     permissions:
@@ -37,6 +38,23 @@ jobs:
       - name: Upgrade pip
         run: python -m pip install -U pip
 
+      - name: Install workspace packages
+        run: |
+          python -m pip install \
+            -e pkgs/tigrcorn-core \
+            -e pkgs/tigrcorn-config \
+            -e pkgs/tigrcorn-asgi \
+            -e pkgs/tigrcorn-contract \
+            -e pkgs/tigrcorn-transports \
+            -e pkgs/tigrcorn-protocols \
+            -e pkgs/tigrcorn-http \
+            -e pkgs/tigrcorn-security \
+            -e pkgs/tigrcorn-runtime \
+            -e pkgs/tigrcorn-static \
+            -e pkgs/tigrcorn-observability \
+            -e pkgs/tigrcorn-compat \
+            -e pkgs/tigrcorn-certification
+
       - name: Install certification dependencies
         run: python -m pip install -e ".[certification,dev]"
 
@@ -64,7 +82,7 @@ jobs:
         run: |
           python -m compileall -q src benchmarks tools
           PYTHONPATH=src pytest -q \
-            tests/test_phase9i_release_assembly_checkpoint.py \
+            tests/test_release_assembly_checkpoint.py \
             tests/test_release_gates.py \
             tests/test_certification_environment_freeze.py \
             tests/test_aioquic_adapter_preflight.py

.github/workflows/publish-pypi.yml

@@ -27,6 +27,22 @@ jobs:
           python-version: "3.12"
       - name: Upgrade pip
         run: python -m pip install --upgrade pip
+      - name: Install workspace packages
+        run: |
+          python -m pip install \
+            -e pkgs/tigrcorn-core \
+            -e pkgs/tigrcorn-config \
+            -e pkgs/tigrcorn-asgi \
+            -e pkgs/tigrcorn-contract \
+            -e pkgs/tigrcorn-transports \
+            -e pkgs/tigrcorn-protocols \
+            -e pkgs/tigrcorn-http \
+            -e pkgs/tigrcorn-security \
+            -e pkgs/tigrcorn-runtime \
+            -e pkgs/tigrcorn-static \
+            -e pkgs/tigrcorn-observability \
+            -e pkgs/tigrcorn-compat \
+            -e pkgs/tigrcorn-certification
       - name: Install project
         run: python -m pip install -e ".[certification,dev]" build
       - name: Build certification and release metadata

.gitignore

@@ -1,3 +1,4 @@
 *.pyc
 /src/tigrcorn.egg-info
+/pkgs/*/src/*.egg-info
 /.tmp

.ssot/MUT.json

@@ -1,5 +1 @@
-{
-  "state": "mutable",
-  "scope": "repo_ssot_root",
-  "reason": "Repo-local canonical machine-readable registry and derived validation outputs."
-}
+{"reason":"Repo-local canonical machine-readable registry and derived validation outputs.","scope":"repo_ssot_root","state":"mutable"}

.ssot/adr/ADR-0615-downstream-assurance-language-ceilings.yaml

@@ -0,0 +1,62 @@
+schema_version: "0.2.0"
+kind: "adr"
+id: "adr:0615"
+number: 615
+slug: "downstream-assurance-language-ceilings"
+title: "Downstream assurance-language ceilings for feature target claim tiers"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "SSOT downstream repositories use feature target claim tiers, linked claims, tests, and evidence to describe what a system can responsibly claim about a feature. The shared `T0` through `T4` tiers describe assurance strength, but downstream reports, release notes, README content, generated summaries, and certification artifacts also need a common language ceiling so weakly evidenced features are not described with stronger assurance language than their proof chains support."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  SSOT downstream repositories use feature target claim tiers, linked claims, tests, and evidence to describe what a system can responsibly claim about a feature. The shared `T0` through `T4` tiers describe assurance strength, but downstream reports, release notes, README content, generated summaries, and certification artifacts also need a common language ceiling so weakly evidenced features are not described with stronger assurance language than their proof chains support.
+  
+  This ADR is an `ssot-origin` decision. It is intended to apply to downstream repositories that synchronize and conform to SSOT origin documents, not only to the `ssot-registry` package repository.
+  
+  ## Decision
+  
+  Downstream SSOT repositories must treat each feature's effective target claim tier as the ceiling for assurance language used in SSOT-controlled outputs. A feature may be described with language from its effective tier or any weaker tier. It must not be described with stronger language unless a linked claim passes claim-closure checks at the stronger tier and the feature evaluation requires or accepts that stronger tier.
+  
+  The effective tier is resolved by the applicable evaluation policy. For direct feature evaluation, use `feature.plan.target_claim_tier`. For profile evaluation, use the feature target tier when present, otherwise the profile claim tier when the profile policy permits that fallback. If no effective tier can be resolved, downstream tooling must fail closed and must not emit assurance claims stronger than inventory-level language.
+  
+  Acceptable language by tier:
+  
+  | Tier | Assurance ceiling | Acceptable claims language |
+  |---|---|---|
+  | `T0` | Declared intent or inventory-level | declared, tracked, intended, planned, in scope, inventory-level support |
+  | `T1` | Maintainer-asserted with local evidence | maintainer-asserted, locally evidenced, supported by local evidence, observed in maintainer-run checks |
+  | `T2` | Reproducible project-controlled verification | reproducibly verified, project-verified, verified by project-controlled tests or CI, repeatably validated |
+  | `T3` | Release-grade certified claim | release-certified, release-grade verified, certified for a named release or frozen boundary |
+  | `T4` | Independently reviewed or externally attested claim | independently reviewed, externally attested, third-party validated, validated by a named external source or artifact |
+  
+  Disallowed escalations:
+  
+  - `T0` features must not be described as working, verified, tested, certified, or attested.
+  - `T1` features must not be described as reproducibly verified, release-certified, or independently reviewed.
+  - `T2` features must not be described as release-certified or independently reviewed.
+  - `T3` features must not be described as independently reviewed or externally attested unless `T4` evidence exists.
+  
+  Canonical wording templates:
+  
+  - `T0`: Feature `<id>` is declared in scope for `<capability>`.
+  - `T1`: Maintainers assert that feature `<id>` supports `<capability>`, backed by local evidence `<evidence-id>`.
+  - `T2`: Feature `<id>` is reproducibly verified by project-controlled checks for `<capability>`.
+  - `T3`: Feature `<id>` is release-certified for `<release-or-boundary>` with passing claim closure at tier `T3` or higher.
+  - `T4`: Feature `<id>` is independently reviewed or externally attested for `<capability>` by `<source-or-artifact>`.
+  
+  Claim status remains orthogonal to claim tier. Status may describe lifecycle progress, but it does not authorize stronger assurance language. Evidence tier alignment, linked test status, and feature target tier evaluation remain the enforcement mechanisms for whether stronger language is valid.
+  
+  ## Consequences
+  
+  Downstream generated summaries, READMEs, release notes, certification reports, review comments, and human-authored SSOT-controlled documentation must choose assurance language from the feature's effective tier or a weaker tier.
+  
+  Downstream projects may adopt stricter vocabulary, additional review gates, or domain-specific phrasing, but they must not permit stronger assurance wording than the feature's passing proof chain supports.
+  
+  Reviewers and automation should treat over-strong assurance language as a policy defect even when the underlying feature is implemented.

.ssot/adr/ADR-1032-package-workspace-boundaries.yaml

@@ -0,0 +1,38 @@
+schema_version: "0.1.0"
+kind: "adr"
+id: "adr:1032"
+number: 1032
+slug: "package-workspace-boundaries"
+title: "Split Tigrcorn into governed workspace packages"
+status: "accepted"
+origin: "repo-local"
+decision_date: null
+tags: []
+summary: "Decision: Tigrcorn shall remain a stable umbrella package while implementation migrates into governed workspace packages with one-way dependencies."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  # ADR 1032 - Package workspace boundaries
+
+  Decision: Tigrcorn shall remain a stable umbrella package while implementation migrates into governed workspace packages with one-way dependencies.
+
+  The monolithic package shape makes long-term protocol, transport, runtime, compatibility, and certification work harder to evolve independently. The project shall use a monorepo workspace so implementation can be split into publishable packages without forcing separate repositories.
+
+  Package ownership:
+
+  - `tigrcorn-core` owns dependency-light constants, exceptions, and type aliases.
+  - `tigrcorn-config`, `tigrcorn-http`, and `tigrcorn-asgi` own reusable lower-layer surfaces.
+  - `tigrcorn-contract`, `tigrcorn-transports`, and `tigrcorn-security` own runtime-adjacent adapters and primitives.
+  - `tigrcorn-protocols`, `tigrcorn-static`, and `tigrcorn-observability` own feature families above those primitives.
+  - `tigrcorn-runtime` composes server runtime behavior.
+  - `tigrcorn-compat` and `tigrcorn-certification` remain leaf packages.
+  - `tigrcorn` remains the umbrella public install and compatibility facade.
+
+  Consequences:
+
+  - Lower layers must not import higher layers.
+  - Optional dependencies belong to the package that owns the optional surface.
+  - Existing public `tigrcorn.*` imports remain stable through compatibility shims during migration.
+  - New implementation work shall target the package that owns the capability.

.ssot/adr/ADR-1033-protocol-scope-fixtures.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.1.0"
+kind: "adr"
+id: "adr:1033"
+number: 1033
+slug: "protocol-scope-fixtures"
+title: "Require protocol and scope fixtures"
+status: "accepted"
+origin: "repo-local"
+decision_date: null
+tags: []
+summary: "Decision: every supported Tigrcorn protocol and ASGI scope type shall have a named fixture with explicit coverage."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  # ADR 1033 - Protocol and scope fixtures
+
+  Decision: every supported Tigrcorn protocol and ASGI scope type shall have a named fixture with explicit coverage.
+
+  Tigrcorn supports several runtime surfaces that can regress independently: HTTP/1.1, HTTP/2, HTTP/3, QUIC, WebSocket, WebTransport, lifespan, custom scopes, and raw-framed/custom protocol paths. These surfaces need durable fixtures so conformance, interoperability, and demo work have stable entry points instead of one-off test setup.
+
+  Fixture policy:
+
+  - Each supported protocol or scope type shall have one fixture feature in the SSOT registry.
+  - Each fixture feature shall identify the fixture artifact and its coverage tests.
+  - Fixture artifacts may be example apps, test fixture clients, or protocol-specific helper modules.
+  - Fixture tests shall fail when a fixture artifact is missing or no coverage path is declared.
+  - Fixture coverage shall remain separate from support claims; a fixture can exist before full runtime support is complete.
+
+  Consequences:
+
+  - Adding a new supported protocol or scope type requires adding a fixture row, SSOT feature, and test linkage.
+  - Removing or renaming a fixture requires updating the manifest and SSOT linkage in the same change.
+  - Certification and local debugging can use the fixture manifest as the stable operator inventory.