Add governed workspace package boundaries for Tigrcorn

.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.

.ssot/adr/ADR-1034-logging-standards-and-formats.yaml

@@ -0,0 +1,40 @@
+schema_version: "0.1.0"
+kind: "adr"
+id: "adr:1034"
+number: 1034
+slug: "logging-standards-and-formats"
+title: "Adopt stdlib logging with governed structured formats"
+status: "accepted"
+origin: "repo-local"
+decision_date: null
+tags: []
+summary: "Decision: Tigrcorn logging shall be based on Python stdlib logging, with governed JSON Lines, syslog, OTEL, and qlog conformance targets."
+supersedes: []
+superseded_by: []
+status_notes: []
+references:
+  - "PEP 282"
+  - "PEP 391"
+  - "RFC 5424"
+  - "JSON Lines"
+  - "OpenTelemetry Logs Data Model"
+body: |-
+  # ADR 1034 - Logging standards and formats
+
+  Decision: Tigrcorn logging shall use Python standard-library logging as the application logging substrate. PEP 282 defines the logger, handler, formatter, filter, level, and record model that Tigrcorn builds on.
+
+  Structured runtime logs shall be tracked as JSON Lines: UTF-8, one valid JSON value per physical line, and newline terminated when written to files or streams. JSON Lines is the governed operator format for machine-readable app/access/error records.
+
+  Syslog interoperability shall be tracked separately as RFC 5424 conformance. RFC 5424 payloads are not the default local file format; they are a transport and envelope compatibility target with explicit message-size and truncation behavior.
+
+  OpenTelemetry support shall be tracked as a telemetry mapping target. Tigrcorn may export metrics/spans independently from app log records, but log correlation fields such as trace_id and span_id remain reserved for OTEL-compatible mapping.
+
+  qlog support shall remain a QUIC/HTTP3 conformance artifact surface. qlog is not the generic application log format; it is a protocol-debug and certification evidence format with its own redaction and schema-version rules.
+
+  Consequences:
+
+  - The default logger remains `logging.getLogger("tigrcorn")`.
+  - File and stream formatters must not invent a second logging framework.
+  - `--structured-log` means JSON Lines-compatible single-record structured output.
+  - PEP 391 dict configuration is a separate feature from Tigrcorn's lightweight logging profile files.
+  - RFC 5424, OTEL logs, and qlog each receive distinct feature rows and conformance tests.

.ssot/adr/ADR-1035-code-style-line-length-and-docstrings.yaml

@@ -0,0 +1,30 @@
+schema_version: "0.1.0"
+kind: "adr"
+id: "adr:1035"
+number: 1035
+slug: "code-style-line-length-and-docstrings"
+title: "Adopt PEP 8 line length and spaCy-style docstrings"
+status: "accepted"
+origin: "repo-local"
+decision_date: null
+tags: []
+summary: "Decision: Tigrcorn source shall follow PEP 8 line-length guidance and use spaCy-style docstrings for public, non-trivial APIs."
+supersedes: []
+superseded_by: []
+status_notes: []
+references:
+  - "PEP 8"
+  - "spaCy docstring style"
+body: |-
+  # ADR 1035 - Code style line length and docstrings
+
+  Decision: Tigrcorn source shall use PEP 8 as the source-code line-length standard: 79 characters for code where practical, and 72 characters for comments and docstrings where practical. Tool-enforced project limits may be wider only when the formatter or established repo policy requires it, but generated logs and runtime payloads are not governed by source-code line length.
+
+  Public, non-trivial modules, classes, and functions shall use spaCy-style docstrings when documentation is needed. The preferred sections are `Args:`, `Returns:`, `Raises:`, and `Yields:` as applicable, with concise prose and no redundant narration.
+
+  Consequences:
+
+  - Runtime log line length is not constrained by PEP 8.
+  - Long literals, generated artifacts, URLs, and protocol examples may exceed source line targets when wrapping would reduce clarity or correctness.
+  - Comments and docstrings should be rewritten for clarity before adding suppression-only formatting.
+  - New logging docs must distinguish source style limits from emitted record size or collector transport limits.