bitexoft-verify 0.2.0__tar.gz

bitexoft_verify-0.2.0/.gitignore

@@ -0,0 +1,55 @@
+# dependencies
+node_modules/
+.venv/
+venv/
+*.egg-info/
+__pycache__/
+*.pyc
+.pytest_cache/
+.ruff_cache/
+.mypy_cache/
+
+# generated
+app/dist/
+dist/
+build/
+app/src/content/catalog.json
+app/src/content/briefs.json
+app/src/content/glossary-detail.json
+app/src/content/check-feedback.json
+verify-report.json
+coverage/
+htmlcov/
+.coverage
+*.tsbuildinfo
+.vite/
+
+# secrets and credentials: a static frontend makes anything in a .env public (docs/business/monetization.md)
+.env
+.env.*
+!.env.example
+*.pem
+*.key
+*.p12
+*.pfx
+id_rsa*
+id_ed25519*
+
+# books: never commit the PDFs (CLAUDE.md)
+*.pdf
+*.epub
+
+# local tooling
+.claude/settings.local.json
+.vscode/
+.idea/
+
+# scratch
+*.log
+*.bak
+*.tmp
+
+# system
+.DS_Store
+Thumbs.db
+Desktop.ini

bitexoft_verify-0.2.0/PKG-INFO

@@ -0,0 +1,139 @@
+Metadata-Version: 2.5
+Name: bitexoft-verify
+Version: 0.2.0
+Summary: Verifica las entregas de los proyectos de Bitexoft: la misma herramienta en tu máquina y en CI.
+Author: Bitexoft
+License: Proprietary
+Keywords: ai,api,education,python,verification
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Education :: Testing
+Requires-Python: >=3.10
+Requires-Dist: tomli>=2.0.1; python_version < '3.11'
+Provides-Extra: api
+Requires-Dist: httpx>=0.27; extra == 'api'
+Requires-Dist: pyyaml>=6.0; extra == 'api'
+Provides-Extra: dev
+Requires-Dist: pytest>=8.0; extra == 'dev'
+Requires-Dist: ruff>=0.6; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# bitexoft-verify
+
+The platform's only definition of "correct". It runs in two places and decides the same
+thing in both:
+
+| Where | When | What it is worth |
+|---|---|---|
+| Your machine | while you work, answers in seconds | informative |
+| GitHub Actions | on every push, pinned, clean environment | **official** |
+
+The difference shows up as `provenance.surface` in the report. The platform marks a
+delivery as verified only on a green CI report.
+
+## Install
+
+Python 3.10 or newer — the version Ubuntu 22.04 LTS ships, so a stock Linux works without
+upgrading anything.
+
+```bash
+pip install bitexoft-verify            # core; one small dependency below 3.11
+pip install 'bitexoft-verify[api]'     # adds what later deliveries need to verify APIs
+```
+
+If pip answers `requires a different Python`, check your version with `python3 -V`. The
+project itself targets a newer Python than the tool does: each delivery's contract states
+what it needs.
+
+## Use
+
+```bash
+bitexoft-verify check A1          # verify A1
+bitexoft-verify check A3          # verify A3 and, on the way, A1 and A2
+bitexoft-verify check A3 --only   # just A3
+bitexoft-verify deliveries        # what this version can verify
+```
+
+Exit codes: `0` all green, `1` something fails, `2` could not even start.
+
+## `bitexoft.toml`
+
+Organise your project however you like. You declare it here and verification reads it
+from here; what is not negotiable is the **shape** of the boundaries, not their names.
+
+```toml
+[project]
+id = "chaos-sports-lab"
+package = "chaoslab"
+
+[layers]
+domain = "chaoslab.domain"
+
+[cli]
+module = "chaoslab"        # run as `python -m chaoslab`
+# main = "main.py"         # or a script, if that is your entry point
+```
+
+## The three gates
+
+- **Acceptance** — that it works: the contract's symbols, impossible objects refused,
+  value semantics, the geometry, the entry point and its exit codes.
+- **Design** — that it is built well: the domain's boundary read from the syntax tree,
+  your tests passing, at least one test that builds an impossible object.
+- **Evidence** — that you understand it. The CLI **does not judge** this gate: it always
+  reports `skip` with a message. You close it on the platform by writing the why and
+  comparing it against the rubric.
+
+A check never fails for something you cannot fix: if an optional dependency or a git tag
+is missing, it **skips** with a message saying what to do.
+
+## Cumulative verification
+
+Verifying A3 also runs A1 and A2, with inherited checks tagged `[A1]`. That is what makes
+the method agile: every delivery leaves the whole project standing, and a regression in
+old work shows up while verifying the new.
+
+## The sample files
+
+Deliveries are verified against files the CLI ships with, not against one you wrote. For
+A1 that is 30 instants crossing all three block states, plus a copy with one coordinate
+off the pitch to check that bad data fails cleanly instead of printing a traceback at the
+user. They are synthetic: no third-party data is distributed here.
+
+## Development
+
+```bash
+pip install -e '.[dev,api]'
+pytest                               # builds a fake learner repository and verifies it
+ruff check .
+python tools/make_fixtures.py        # regenerate the sample files
+```
+
+Before changing what a check says when it fails, or the layout of the output, read
+[`docs/foundations/03-feedback-self-explanation-calibration.md`](../docs/foundations/03-feedback-self-explanation-calibration.md)
+(the verifier's messages are the feedback a learner reads) and ADR 0002. The check ids and the report
+schema are a contract with the platform: do not rename them.
+
+## Releasing
+
+The version is written once, in `__version__` (`src/bitexoft_verify/__init__.py`). The pin in
+`.github/workflows/verify.yml` (`cli-version`) must match its `major.minor`; a test checks it.
+
+First release, by hand on pypi.org:
+
+1. Account → Publishing → *Add a pending publisher*: project `bitexoft-verify`, owner `bitexoft`,
+   repository `sports-lab-v1`, workflow `release-verify.yml`, environment `pypi`.
+2. In the repository settings, create the environment `pypi`.
+
+Each release:
+
+```bash
+git tag verify-v0.2.0 && git push origin verify-v0.2.0
+```
+
+The workflow runs `pytest` on 3.10 and 3.12, refuses a tag that differs from `__version__`, builds
+with `python -m build` and publishes with trusted publishing (no tokens). Check it in a clean
+environment: `pipx run --spec bitexoft-verify bitexoft-verify deliveries`.

bitexoft_verify-0.2.0/README.md

@@ -0,0 +1,116 @@
+# bitexoft-verify
+
+The platform's only definition of "correct". It runs in two places and decides the same
+thing in both:
+
+| Where | When | What it is worth |
+|---|---|---|
+| Your machine | while you work, answers in seconds | informative |
+| GitHub Actions | on every push, pinned, clean environment | **official** |
+
+The difference shows up as `provenance.surface` in the report. The platform marks a
+delivery as verified only on a green CI report.
+
+## Install
+
+Python 3.10 or newer — the version Ubuntu 22.04 LTS ships, so a stock Linux works without
+upgrading anything.
+
+```bash
+pip install bitexoft-verify            # core; one small dependency below 3.11
+pip install 'bitexoft-verify[api]'     # adds what later deliveries need to verify APIs
+```
+
+If pip answers `requires a different Python`, check your version with `python3 -V`. The
+project itself targets a newer Python than the tool does: each delivery's contract states
+what it needs.
+
+## Use
+
+```bash
+bitexoft-verify check A1          # verify A1
+bitexoft-verify check A3          # verify A3 and, on the way, A1 and A2
+bitexoft-verify check A3 --only   # just A3
+bitexoft-verify deliveries        # what this version can verify
+```
+
+Exit codes: `0` all green, `1` something fails, `2` could not even start.
+
+## `bitexoft.toml`
+
+Organise your project however you like. You declare it here and verification reads it
+from here; what is not negotiable is the **shape** of the boundaries, not their names.
+
+```toml
+[project]
+id = "chaos-sports-lab"
+package = "chaoslab"
+
+[layers]
+domain = "chaoslab.domain"
+
+[cli]
+module = "chaoslab"        # run as `python -m chaoslab`
+# main = "main.py"         # or a script, if that is your entry point
+```
+
+## The three gates
+
+- **Acceptance** — that it works: the contract's symbols, impossible objects refused,
+  value semantics, the geometry, the entry point and its exit codes.
+- **Design** — that it is built well: the domain's boundary read from the syntax tree,
+  your tests passing, at least one test that builds an impossible object.
+- **Evidence** — that you understand it. The CLI **does not judge** this gate: it always
+  reports `skip` with a message. You close it on the platform by writing the why and
+  comparing it against the rubric.
+
+A check never fails for something you cannot fix: if an optional dependency or a git tag
+is missing, it **skips** with a message saying what to do.
+
+## Cumulative verification
+
+Verifying A3 also runs A1 and A2, with inherited checks tagged `[A1]`. That is what makes
+the method agile: every delivery leaves the whole project standing, and a regression in
+old work shows up while verifying the new.
+
+## The sample files
+
+Deliveries are verified against files the CLI ships with, not against one you wrote. For
+A1 that is 30 instants crossing all three block states, plus a copy with one coordinate
+off the pitch to check that bad data fails cleanly instead of printing a traceback at the
+user. They are synthetic: no third-party data is distributed here.
+
+## Development
+
+```bash
+pip install -e '.[dev,api]'
+pytest                               # builds a fake learner repository and verifies it
+ruff check .
+python tools/make_fixtures.py        # regenerate the sample files
+```
+
+Before changing what a check says when it fails, or the layout of the output, read
+[`docs/foundations/03-feedback-self-explanation-calibration.md`](../docs/foundations/03-feedback-self-explanation-calibration.md)
+(the verifier's messages are the feedback a learner reads) and ADR 0002. The check ids and the report
+schema are a contract with the platform: do not rename them.
+
+## Releasing
+
+The version is written once, in `__version__` (`src/bitexoft_verify/__init__.py`). The pin in
+`.github/workflows/verify.yml` (`cli-version`) must match its `major.minor`; a test checks it.
+
+First release, by hand on pypi.org:
+
+1. Account → Publishing → *Add a pending publisher*: project `bitexoft-verify`, owner `bitexoft`,
+   repository `sports-lab-v1`, workflow `release-verify.yml`, environment `pypi`.
+2. In the repository settings, create the environment `pypi`.
+
+Each release:
+
+```bash
+git tag verify-v0.2.0 && git push origin verify-v0.2.0
+```
+
+The workflow runs `pytest` on 3.10 and 3.12, refuses a tag that differs from `__version__`, builds
+with `python -m build` and publishes with trusted publishing (no tokens). Check it in a clean
+environment: `pipx run --spec bitexoft-verify bitexoft-verify deliveries`.

bitexoft_verify-0.2.0/pyproject.toml

@@ -0,0 +1,58 @@
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "bitexoft-verify"
+dynamic = ["version"]
+description = "Verifica las entregas de los proyectos de Bitexoft: la misma herramienta en tu máquina y en CI."
+readme = "README.md"
+requires-python = ">=3.10"
+license = { text = "Proprietary" }
+authors = [{ name = "Bitexoft" }]
+keywords = ["education", "verification", "python", "api", "ai"]
+classifiers = [
+  "Programming Language :: Python :: 3 :: Only",
+  "Programming Language :: Python :: 3.10",
+  "Programming Language :: Python :: 3.11",
+  "Programming Language :: Python :: 3.12",
+  "Programming Language :: Python :: 3.13",
+  "Topic :: Education :: Testing",
+]
+# The core stays dependency-free on modern interpreters: it installs in seconds and
+# collides with nothing in the learner's environment. The single conditional dependency
+# is the TOML reader, which is stdlib from 3.11 onwards.
+dependencies = ["tomli>=2.0.1; python_version < '3.11'"]
+
+[project.optional-dependencies]
+api = ["httpx>=0.27", "PyYAML>=6.0"]
+dev = ["pytest>=8.0", "ruff>=0.6"]
+
+[project.scripts]
+bitexoft-verify = "bitexoft_verify.cli:main"
+
+# One source of truth for the version: `__version__`. The release workflow, the pin in
+# `.github/workflows/verify.yml` and `pip show` all read it from there.
+[tool.hatch.version]
+path = "src/bitexoft_verify/__init__.py"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/bitexoft_verify"]
+
+
+[tool.ruff]
+line-length = 120
+target-version = "py310"
+
+[tool.ruff.lint]
+select = ["E", "F", "I", "UP", "B", "SIM"]
+# UP017 rewrites timezone.utc to datetime.UTC, which does not exist before 3.11.
+ignore = ["UP017"]
+
+[tool.ruff.lint.per-file-ignores]
+# Los tests construyen el código del repositorio falso con replace() sobre literales:
+# partir esas líneas los hace ilegibles.
+"tests/*" = ["E501"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]

bitexoft_verify-0.2.0/src/bitexoft_verify/__init__.py

@@ -0,0 +1,3 @@
+"""bitexoft-verify: the platform's only definition of "correct"."""
+
+__version__ = "0.2.0"

bitexoft_verify-0.2.0/src/bitexoft_verify/__main__.py

@@ -0,0 +1,4 @@
+from .cli import main
+
+if __name__ == "__main__":
+    raise SystemExit(main())

bitexoft_verify-0.2.0/src/bitexoft_verify/checks/__init__.py

@@ -0,0 +1 @@
+"""Checks, one module per delivery."""