causal-continuity-engine 0.1.0__tar.gz

causal_continuity_engine-0.1.0/.editorconfig

@@ -0,0 +1,15 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 2
+
+[*.py]
+indent_size = 4
+
+[Makefile]
+indent_style = tab

causal_continuity_engine-0.1.0/.gitattributes

@@ -0,0 +1,21 @@
+# Canonicalize every committed text blob as LF, whatever platform authored it.
+# The index blobs were already LF when this rule was enabled; a pre-existing
+# Windows worktree may still need a fresh checkout before exact release checks.
+* text=auto eol=lf
+
+# Shell scripts must stay LF even in a Windows working tree or /bin/sh will
+# not run them. The git hooks are shell scripts with no .sh extension.
+*.sh text eol=lf
+.githooks/* text eol=lf
+*.bat text eol=crlf
+
+# Binary: never normalize line endings, never diff as text.
+*.png -text
+
+# Language statistics. docs/ is prose about the engine, not engine code.
+docs/** linguist-documentation
+
+# The conformance corpus is produced by vectors/generate.py and checked back
+# in; `python3 vectors/generate.py --check` is what validates it, not review
+# of the JSON by hand. vectors/generate.py itself stays counted as source.
+vectors/*.json linguist-generated

causal_continuity_engine-0.1.0/.githooks/commit-msg

@@ -0,0 +1,19 @@
+#!/bin/sh
+PATTERN='co-authored-by:.*(anthropic|chatgpt|claude|codex|copilot|gemini|openai)|noreply@(anthropic|openai)\.com|generated (with|by)[[:space:]]+\[?(chatgpt|claude|codex|copilot|gemini|openai)'
+identity_input="$(mktemp)" || exit 1
+trap 'rm -f "$identity_input"' EXIT HUP INT TERM
+cat "$1" > "$identity_input" || exit 1
+git var GIT_AUTHOR_IDENT >> "$identity_input" || exit 1
+grep_status=0
+grep -nEi "$PATTERN" "$identity_input" || grep_status=$?
+case "$grep_status" in
+    0)
+        echo "ERROR: AI attribution in commit message or author identity. Remove it." >&2
+        exit 1
+        ;;
+    1) ;;
+    *)
+        echo "ERROR: grep failed; attribution status is unknown." >&2
+        exit "$grep_status"
+        ;;
+esac

causal_continuity_engine-0.1.0/.githooks/pre-commit

@@ -0,0 +1,61 @@
+#!/bin/sh
+# Repository pre-commit gate. Attribution is blocking; gitleaks is blocking
+# when installed and emits an explicit warning when unavailable.
+#
+# WHY BOTH LIVE HERE: git honours exactly one hook path. This repository sets
+# `core.hooksPath = .githooks`, and the pre-commit framework refuses to install
+# while that is set ("Cowardly refusing to install hooks with `core.hooksPath`
+# set"). Keeping the secret scan only in .pre-commit-config.yaml therefore meant
+# a maintainer with the repo's hook path configured got the attribution guard
+# and NO secret scan, while a contributor who ran `pre-commit install` got the
+# reverse. Either way exactly one gate was live, and nothing said which.
+#
+# .pre-commit-config.yaml remains supported for contributors who prefer the
+# framework: unset core.hooksPath first. CI enforces the attribution rule
+# independently (.github/workflows/no-ai-attribution.yml), so a contributor who
+# runs neither hook path is still caught before merge.
+
+# ---------------------------------------------------------------- attribution
+# The three enforcement files necessarily contain the expression they search
+# for, so only those exact files are excluded. No directory is exempt.
+PATTERN='co-authored-by:.*(anthropic|chatgpt|claude|codex|copilot|gemini|openai)|noreply@(anthropic|openai)\.com|generated (with|by)[[:space:]]+\[?(chatgpt|claude|codex|copilot|gemini|openai)'
+# Search the proposed index tree rather than raw diff text. Deleted lines must
+# not prevent the commit that removes a violation.
+git_grep_status=0
+git grep --cached -nEi "$PATTERN" -- . \
+  ':(exclude).githooks/pre-commit' \
+  ':(exclude).githooks/commit-msg' \
+  ':(exclude).github/workflows/no-ai-attribution.yml' \
+  || git_grep_status=$?
+case "$git_grep_status" in
+    0)
+        echo "ERROR: AI attribution found in staged changes. Remove it before committing." >&2
+        exit 1
+        ;;
+    1) ;;
+    *)
+        echo "ERROR: git grep failed; attribution status is unknown." >&2
+        exit "$git_grep_status"
+        ;;
+esac
+
+# --------------------------------------------------------------------- secrets
+# Load-bearing, not decoration. GitHub secret scanning and push protection are
+# unavailable here (private repository, personal Pro plan). When gitleaks is
+# installed and this hook is not bypassed, it is the only local scan before a
+# pasted credential reaches the remote; the server workflow runs after push.
+# .gitleaks.toml allowlists the synthetic token the redaction tests need by
+# VALUE rather than by path, so a real secret in the same file is still caught.
+if command -v gitleaks >/dev/null 2>&1; then
+    if ! gitleaks git --staged --config .gitleaks.toml --redact --no-banner; then
+        echo "ERROR: gitleaks flagged a potential secret in the staged changes." >&2
+        echo "If it is a synthetic test value, allowlist it BY VALUE in .gitleaks.toml." >&2
+        exit 1
+    fi
+else
+    # Warn rather than refuse. A fresh clone has no gitleaks, and blocking every
+    # commit until it is installed teaches people to reach for --no-verify,
+    # which would disable the attribution guard above as well.
+    echo "WARNING: gitleaks is not installed - the secret scan did NOT run." >&2
+    echo "  brew install gitleaks   (or use .pre-commit-config.yaml)" >&2
+fi

causal_continuity_engine-0.1.0/.github/CODEOWNERS

@@ -0,0 +1,45 @@
+# Code owners for the Causal Continuity Engine.
+#
+# HOW THIS FILE IS READ: the LAST pattern that matches a file wins — not the
+# first, and not the most specific. So the catch-all is written first and the
+# high-sensitivity paths follow it, in order of increasing sensitivity, so
+# that they are matched last and therefore win. Adding a new broad pattern at
+# the bottom would silently take ownership of everything below it.
+#
+# Syntax note: GitHub's CODEOWNERS does not support "!" negation or "[ ]"
+# character ranges. Every pattern here is a plain gitignore-style path.
+#
+# One maintainer owns everything today, so every line names the same owner and
+# nothing here changes who can merge — GitHub does not request review from the
+# author of a pull request, and there is no second reviewer to request. The
+# file earns its place because it makes sensitive-path changes visible in
+# review and predeclares the paths that should gain an additional owner. When
+# a second maintainer is added, edit the relevant patterns to name that
+# reviewer; collaborator status alone does not change the owners listed here.
+
+# Everything, unless a later line says otherwise.
+*                       @thequantumfalcon
+
+# Repository automation: CI, the attribution guard, this policy set.
+/.github/               @thequantumfalcon
+
+# Commit-time enforcement. A change here can disable the guards.
+/.githooks/             @thequantumfalcon
+
+# The normative proof-envelope specification. Changing this text changes what
+# every implementation is required to do.
+/SPEC.md                @thequantumfalcon
+
+# The independent verifier, and the conformance corpus that is the arbiter
+# between it and the reference implementation.
+/verifiers/             @thequantumfalcon
+/vectors/               @thequantumfalcon
+
+# The trust layer: envelope construction and verification, the verifier
+# policy, and the completion gate that refuses a task without a valid proof.
+/causal_continuity_engine/proof.py           @thequantumfalcon
+/causal_continuity_engine/policy.py          @thequantumfalcon
+/causal_continuity_engine/engine.py          @thequantumfalcon
+
+# The decision record. Entries are appended, not rewritten.
+/docs/adr/              @thequantumfalcon

causal_continuity_engine-0.1.0/.github/CONTRIBUTING.md

@@ -0,0 +1,260 @@
+# Contributing to the Causal Continuity Engine
+
+This project makes a narrow, checkable claim: that a coding agent's work can be
+resumed, invalidated, and completed under proof, and that the checks doing the
+deciding actually run in the path that decides. Contributions are welcome to
+the extent they hold that claim up. The bar is not politeness or volume, it is
+evidence.
+
+Read [`docs/adr/ADR-INDEX.md`](../docs/adr/ADR-INDEX.md) before proposing a
+change. Most design questions a newcomer has are answered there, usually
+because the naive answer was tried, shipped, and broken by a later review
+round.
+
+## The trust core is change-controlled
+
+The 0.1.0 trust core has a high change bar. It is not literally frozen:
+post-round-7 review added operator receipts, policy configuration, and
+transactional race hardening. New subsystems require a proposal issue and the
+same reproduce-first, adversarial evidence expected of a defect fix.
+
+**In scope**
+
+- Defect fixes, with a reproduction (see below).
+- Corrections to `SPEC.md` where it is ambiguous, or where
+  `verifiers/verify_proof.py` is faithful to the text and the text is wrong.
+  Round 7's worst finding was of exactly this kind: the implementation was
+  correct and the specification was not.
+- New conformance vectors in `vectors/` that pin a case both implementations
+  should already agree on, or that catch a drift they could fall into.
+- Portability fixes to `verifiers/verify_proof.py`, which must stay standard
+  library only and must never import from `causal_continuity_engine`.
+- Documentation that is wrong, stale, or overstated. Claims that outrun the
+  code are treated as defects, not as marketing.
+
+**Not in scope**
+
+- New subsystems, new memory tiers, new trigger types, new verifier kinds.
+- Restructuring. `causal_continuity_engine/` is a flat layout, not `src/`,
+  deliberately. `tests/`
+  lives at the repository root, outside the package, deliberately.
+- Converting `docs/adr/ADR-INDEX.md` to MADR or any other ADR format.
+- Any third-party runtime dependency. `causal_continuity_engine/` is standard
+  library only, and
+  `just deps` fails if that stops being true.
+
+If you think something belongs in the engine anyway, open a proposal issue
+first and argue it there. Do not smuggle feature scope into an unrelated fix.
+
+## Setup
+
+Python 3.11 or newer. The engine has no runtime dependencies, but the checks
+do. `just setup` installs every direct and transitive tool from
+`requirements-dev.lock` in pip's all-or-nothing hash-checking mode, refuses
+source distributions, then installs `causal-continuity-engine` editable without dependency
+resolution or an isolated build environment. The reviewed direct inputs are
+`pytest` 9.1.1, `ruff` 0.16.1, `build` 1.5.0, `jsonschema` 4.26.0,
+`setuptools` 83.0.0, and `pip` 26.1.2. None is imported by the engine; jsonschema validates
+emitted receipt instances only in the test/release gate.
+
+The pins were revalidated on 2026-08-04. Setuptools 83.0.0 and pip 26.1.2
+are the first patched releases for
+[GHSA-h35f-9h28-mq5c](https://github.com/advisories/GHSA-h35f-9h28-mq5c)
+and [GHSA-wf93-45jw-7689](https://github.com/advisories/GHSA-wf93-45jw-7689);
+pytest 9.1.1 is newer than the 9.0.3 fix for
+[GHSA-6w46-j5rx-g56g](https://github.com/advisories/GHSA-6w46-j5rx-g56g),
+and the lock carries Pygments 2.20.0, the fix for
+[GHSA-5239-wwwm-4pmq](https://github.com/advisories/GHSA-5239-wwwm-4pmq).
+Build remains at 1.5.0 because PyPI marks 1.5.1 yanked; jsonschema 4.26.0 and
+ruff 0.16.1 were the current stable releases on that date. This is a dated
+review record, not a claim that pins stay current without future review.
+
+When a direct pin changes, edit `pyproject.toml` and `requirements-dev.in`,
+regenerate the lock with the command recorded in its header, and review the
+complete dependency and hash diff. A regression requires those direct inputs
+to remain identical and every locked requirement to carry a SHA-256 hash.
+
+Your Python interpreter, `venv`, and its initial `ensurepip`/pip are bootstrap
+trust: the initial pip installs the hashed closure once. That closure includes
+the reviewed pip pin, and the bootstrap verifies every distribution version
+and origin inside the new environment before it runs repository gates.
+
+```bash
+git clone https://github.com/thequantumfalcon/causal-continuity-engine.git
+cd causal-continuity-engine
+just setup                            # editable engine + pinned dev/release checks
+git config core.hooksPath .githooks   # attribution scan AND gitleaks, both blocking
+brew install gitleaks                 # or a release binary from gitleaks/gitleaks
+just test                             # should be green before you change anything
+```
+
+Install gitleaks. It is load-bearing here, not decoration: GitHub's native
+secret scanning and repository push protection are unavailable on this private
+personal-account repository. The local hook catches a credential before it
+leaves the machine; the `secrets` workflow scans pull requests, pushes to
+`main`, and the full history weekly. The hook warns rather than refuses when
+gitleaks is missing, so that server-side scan remains visible after a local
+`--no-verify`. The committed ruleset makes it merge-blocking, but the live
+ruleset still requires only `ci`; see `.github/ruleset.README.md`. If a
+synthetic test value trips the scan,
+allowlist it in `.gitleaks.toml` by value, never by path, so a real secret in
+the same file is still caught.
+
+`.pre-commit-config.yaml` remains supported for contributors who prefer the
+framework, with one constraint: git honours exactly one hook path, and
+pre-commit refuses to install while `core.hooksPath` is set. Unset it first
+(`git config --unset core.hooksPath`). That path covers gitleaks, `ruff check` (the same
+lint gate as `just lint` and CI) and file hygiene, but not the attribution
+scan. It deliberately carries no `ruff-format` hook — see the `fmt-check` note
+in the `justfile`. CI enforces the attribution rule independently either way
+(`.github/workflows/no-ai-attribution.yml`), so nothing that reaches a pull
+request depends on which hook path you chose.
+
+Focused recipes live in the `justfile`. Hosted Linux, Windows, macOS, and release
+jobs all invoke the checked-in standard-library
+`.github/scripts/run_gates.py`, avoiding a downloaded command runner in the
+trusted path. `just check` calls the same aggregate locally; every focused
+equivalent below is cross-platform.
+
+## Gates
+
+All six focused behavioral recipes — lint, dependency-boundary scan, tests,
+corpus, capability audit, and benchmark — must pass locally before you open a
+pull request. `just build` is additionally required when packaging, generated
+assets, or release machinery changes. Hosted CI runs the six-recipe aggregate
+across Python 3.11, 3.12, 3.13, and 3.14, repeats it natively on Windows 3.14
+and macOS 15 ARM64/Python 3.14, and always builds twice and audits an installed
+wheel. The `ci` job fans all those paths into one context.
+
+| Recipe | Direct equivalent | What it establishes |
+|---|---|---|
+| `just setup` | `python -m pip install --force-reinstall --require-hashes --only-binary=:all: -r requirements-dev.lock`, then `python -m pip check`, then `python -m pip install --no-deps --no-build-isolation -e .` | Nothing on its own. It installs the reviewed, hash-locked tool closure, checks dependency consistency, and installs the local package without undeclared resolution. |
+| `just lint` | `python -m ruff check .` | Ruff passes under the rule set pinned in `pyproject.toml` `[tool.ruff.lint]` — `E`, `F`, `W`, `I`, line length 100. That set, and nothing wider: it is not passed on the command line, so widening the gate means editing `pyproject.toml`. |
+| `just deps` | `python .github/scripts/check_stdlib.py` | `causal_continuity_engine/` imports nothing outside the standard library. It parses the AST instead of importing, so a lazy, guarded, or function-local import is caught too. This is the gate behind the zero-runtime-dependency claim. |
+| `just test` | `python -m pytest tests/ -q` | The complete regression suite and planted instrument-validation cases pass. |
+| `just corpus` | `python vectors/generate.py --check` | The reference implementation still reaches every committed verdict. Cross-implementation agreement is established by `just test`, not here. |
+| `just caps` | `python -m causal_continuity_engine.capabilities --write` then `git diff --exit-code -- docs/CAPABILITIES.md` | Every capability claim resolves to real symbols, files, and tests, and the committed `docs/CAPABILITIES.md` is identical to what the audit generates. |
+| `just bench` | `python -m benchmarks.continuitybench.run` | All ten ContinuityBench scenarios still pass and all six metrics are still at their gates. |
+| `just build` | the scripts under `.github/scripts/` | Each pass first binds physical source bytes without Git filters to the exact `HEAD`/index blobs, stages only those bytes in an empty disposable source directory, validates a canonical closed-manifest sdist before materializing it, and builds the wheel only from that exact normalized payload; two passes are byte-identical under the locked backend, backend execution leaves source unchanged, the checksum manifest is exact, shipped bytes equal the source tree, the audit surface is present, and an isolated installed wheel passes dependency-free import/CLI probes before exact locked tools run capability and behavioral checks. |
+
+Attribution is not one of these, and it is not a lint rule. It is enforced by
+`.githooks/pre-commit` locally and by the `attribution` job in
+`.github/workflows/no-ai-attribution.yml`. The committed desired ruleset
+requires both `attribution` and `secrets`; the live ruleset does not yet,
+and that operational drift is a blocker documented in
+`.github/ruleset.README.md`.
+
+`docs/CAPABILITIES.md` is generated, never hand-edited. If your change moves a
+symbol a claim points at, run
+`python -m causal_continuity_engine.capabilities --write` and commit
+the result: `just caps` regenerates the table and then requires a clean
+`git diff` for it, so a stale or hand-edited copy fails the gate.
+
+Two limits worth stating, because they set expectations for review. The
+capability audit proves a symbol resolves and that the table on disk is current
+— it cannot see a control that exists but does not run in the path that
+decides, which is the shape of three
+of this project's worst defects (ADR-014, ADR-043, ADR-044). Instrument
+validation only proves each gate distinguishes its own case; it says nothing
+about whether the set of gates is complete (ADR-056, ADR-067). Green gates are
+a floor, not a verdict.
+
+## Reproduction first
+
+A bug fix is not reviewable without a reproduction. The order is not
+negotiable:
+
+1. **Reproduce it against the released code, by hand.** Drive the CLI or the
+   engine API the way a user would. Put the exact commands and the exact
+   output in the issue or the pull request body.
+2. **Write the regression test and watch it fail against the pre-fix code.**
+   State in the pull request that you did this, and what the failure looked
+   like. A test that has only ever been run against the fixed code proves
+   nothing about the bug.
+3. **Then fix it,** and show the same test passing.
+
+The reason is on the record. In round 4 the first version of the ADR-024 fix
+left the default configuration exploitable while every new test passed,
+because the tests all used the pinned form the fix had introduced. Running the
+original attack verbatim against the built artifact is what caught it. Tests
+written alongside a fix inherit the fix's assumptions; the attack does not.
+
+A fix is a change like any other and earns its own adversarial pass. Two
+defects in this repository were introduced by an earlier round's fixes and
+found only because the fixes themselves were re-reviewed.
+
+If your change touches a rejection path in `complete_task`, it also needs a
+planted-defect case in `tests/test_instrument_validation.py` naming which gate
+should catch it. A defect caught by the wrong gate is a mismatch, not a pass.
+
+## Commits and pull requests
+
+**The pull request title must be a Conventional Commit.** Everything is merged
+by squash, so the title becomes the permanent commit subject on `main` — it is
+what `git log` shows a year from now, and it is what GitHub's generated release
+notes list, sorted into sections by label per `.github/release.yml`. Your
+Individual branch commits do not drive release notes, but the attribution
+gate scans every commit message, author name, and author email. Keep them
+descriptive and compliant even though the squash title is the permanent
+subject on `main`.
+
+```
+fix(proof): reject an envelope whose recorded status contradicts its checks
+docs(spec): state that §4 and §5 hash different bodies
+test(regressions): pin the round-7 retention/rebuild boundary
+```
+
+Use `feat`, `fix`, `docs`, `test`, `refactor`, or `chore` — the same set
+`.github/pull_request_template.md` lists. Given the trust core's change bar,
+`feat` usually needs an accepted proposal issue before implementation. Mark a
+breaking change to the
+`cce.proof.v1` envelope, the schemas, or the CLI with `!` before the colon,
+explain it in the body, and label the pull request `breaking` so the release
+notes file it under Breaking Changes.
+
+Nothing derives a changelog or version bump from commit subjects. Releases are
+operator-triggered: `just release` runs the complete clean-tree and
+reproducibility gate locally, then a signed annotated tag matching the package
+version triggers `.github/workflows/release.yml`. The workflow verifies the
+tag on GitHub, requires the commit on `main` with trusted exact-SHA checks,
+repeats every gate under read-only permissions, and hands the exact wheel,
+sdist, and checksum manifest to a separate draft-to-final publish job. See
+`docs/RELEASE.md`.
+
+**Sign off your commits.** Contributions are accepted under the
+[Developer Certificate of Origin 1.1](https://developercertificate.org/), and
+external contributions are asked for a
+`Signed-off-by` trailer:
+
+```bash
+git commit -s -m "fix(graph): bound traversal at the configured budget"
+```
+
+This is not enforced today. There is no DCO app, workflow, or `commit-msg`
+check for the trailer, so a pull request is not yet blocked for missing it.
+Existing history predates enforcement and is not being rewritten merely to
+add trailers. The DCO app will be enabled, and its check made required, when
+the repository goes public. `git rebase --signoff` will add the trailer if you
+forget it on an unpublished branch. By signing off you certify the DCO's terms
+and license your contribution under the repository's Apache-2.0 license.
+
+Keep the branch focused. One defect, one pull request. Do not reformat
+adjacent code, rename things you did not introduce, or clean up unrelated dead
+code in passing — mention it instead. Diff noise is treated as a defect,
+because a review that has to separate intent from noise is a worse review.
+
+## Two standing rules
+
+**Absence of success is never success.** A check that did not run detected
+nothing, a probe that crashed found nothing, and an empty required-verifier
+list verifies nothing. If your change can produce a "nothing went wrong"
+outcome, say what distinguishes it from "nothing happened".
+
+**No authorship attribution to tooling.** The `.githooks/` hooks and the CI
+attribution guard both reject it, in commit messages and in committed files.
+Do not work around them.
+
+## Security
+
+Do not open a public issue for a vulnerability. Follow
+[SECURITY.md](SECURITY.md).

causal_continuity_engine-0.1.0/.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,125 @@
+name: Bug report
+description: The engine does something that contradicts its documented behaviour.
+title: "bug: "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        A bug report is a claim about behaviour, and the claim has to carry
+        enough for someone else to reproduce it on a machine you do not
+        control. A report that cannot be reproduced is not necessarily wrong,
+        but there is nothing in it to act on.
+
+        Before filing, check that what you are seeing is not a limit that is
+        already written down. `docs/CAPABILITIES.md` records the honest limit
+        of every capability claim — `implemented` there means the mechanism
+        exists and is tested, never that the requirement is solved in full.
+        `SPEC.md` section 11 lists what the proof envelope specification
+        deliberately does not cover.
+
+  - type: dropdown
+    id: subsystem
+    attributes:
+      label: Subsystem
+      description: A best guess is fine. Pick "Not sure / other" if it does not fit.
+      options:
+        - Engine and causal graph
+        - Resume packet
+        - Proof envelope and completion gate
+        - Evidence probes and grading
+        - Invalidation and blast radius
+        - Memory tiers
+        - CLI
+        - Standalone verifier (verifiers/verify_proof.py)
+        - Not sure / other
+    validations:
+      required: true
+
+  - type: textarea
+    id: ran
+    attributes:
+      label: What you ran
+      description: The exact command or API call, verbatim, including every flag.
+      render: shell
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: What you expected
+      description: >-
+        If the expectation comes from a document, cite it: a SPEC.md section,
+        an ADR number from docs/adr/ADR-INDEX.md, a row in docs/CAPABILITIES.md,
+        or a line in the README. An expectation with a source is a much stronger
+        report than one without.
+    validations:
+      required: true
+
+  - type: textarea
+    id: actual
+    attributes:
+      label: What happened
+      description: >-
+        The output verbatim, including the exit code and any traceback.
+        Paraphrasing loses the detail that usually turns out to matter.
+      render: shell
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Minimal reproduction
+      description: >-
+        The shortest sequence that reaches the wrong behaviour starting from a
+        fresh project — `cce-engine init` and then the fewest steps that show it, or a
+        failing test. Strip out everything that is not needed to make it happen.
+        A report without a reproduction cannot be acted on. If the bug needs a
+        particular database, proof envelope, or webhook payload, attach it with
+        anything private removed.
+      render: shell
+    validations:
+      required: true
+
+  - type: input
+    id: cce-version
+    attributes:
+      label: CCE version
+      description: >-
+        `python -c "from causal_continuity_engine import __version__; print(__version__)"`, or the version in
+        causal_continuity_engine/__init__.py. If you are running from a checkout,
+        give the commit SHA
+        instead — it is more precise than the version string.
+      placeholder: "0.1.0, or a commit SHA"
+    validations:
+      required: true
+
+  - type: input
+    id: python-version
+    attributes:
+      label: Python version
+      description: The full output of `python -V`. The engine requires 3.11 or newer.
+      placeholder: "Python 3.12.4"
+    validations:
+      required: true
+
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+      description: Name, version, and architecture.
+      placeholder: "macOS 15.5 arm64, or Ubuntu 24.04 x86_64"
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: documented-limits
+    attributes:
+      label: Documented limits
+      options:
+        - label: >-
+            I checked `docs/CAPABILITIES.md` and section 11 of `SPEC.md`, and what
+            I am reporting is not one of the limits recorded there.
+          required: true

causal_continuity_engine-0.1.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Questions
+    url: https://github.com/thequantumfalcon/causal-continuity-engine/discussions
+    about: Ask and answer questions here.
+  - name: Security report
+    url: https://github.com/thequantumfalcon/causal-continuity-engine/security/policy
+    about: Read the security policy before reporting. Never open a public issue for a vulnerability.

causal_continuity_engine-0.1.0/.github/ISSUE_TEMPLATE/feature.yml

@@ -0,0 +1,59 @@
+name: Proposal
+description: A spec clarification, a documentation fix, or a verifier or tooling proposal.
+title: "proposal: "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        The trust core is change-controlled, not frozen. A new surface costs
+        new gates, conformance evidence, and an adversarial pass showing it did
+        not weaken existing controls. This proposal form is where that scope is
+        argued before implementation.
+
+        In scope:
+
+        - clarifications and corrections to `SPEC.md`, which is normative
+        - conformance vectors that pin behaviour the spec already requires
+        - documentation that is wrong, missing, or misleading
+        - verifiers and tooling that live outside `causal_continuity_engine/` — another independent
+          implementation of the spec, a checker, a CI job
+
+        Rejected without prior design agreement: new engine subsystems, event
+        or edge types, or CLI subcommands. Always out of scope: anything that
+        would make `causal_continuity_engine/` depend on a package outside the standard library.
+
+        If the engine is wrong rather than incomplete, file a bug report instead.
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem does this solve
+      description: >-
+        Describe the situation you are actually in, not the change you want.
+        Concrete beats general: what did you try to do, and where did it stop?
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: What you are proposing
+      description: >-
+        The specific change. For a spec clarification, quote the sentence that is
+        ambiguous and give the reading you think is correct.
+    validations:
+      required: true
+
+  - type: textarea
+    id: why-not-outside
+    attributes:
+      label: Why can this not be done outside the engine
+      description: >-
+        The engine exposes an event log, a CLI, an HTTP API, JSON schemas, and a
+        normative spec that a stranger can implement against. Explain what stops
+        this from being built on top of those instead of inside `causal_continuity_engine/`. If the
+        answer is that the engine does not expose enough, say precisely what is
+        missing — that is a narrower and much more likely change.
+    validations:
+      required: true