the-loopy-one 0.2.1__tar.gz

the_loopy_one-0.2.1/.gitignore

@@ -0,0 +1,231 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# the-loop CLI runtime artifacts
+.the-loop/*.pid
+cli/build/
+cli/dist/
+cli/*.egg-info/
+cli/.pytest_cache/
+
+# the-loop: not-yet-durable learning candidates (write-gate queue)
+.the-loop/learnings-pending/
+
+# the-loop: webhook->session routing registry (runtime state)
+.the-loop/sessions/

the_loopy_one-0.2.1/PKG-INFO

@@ -0,0 +1,151 @@
+Metadata-Version: 2.4
+Name: the-loopy-one
+Version: 0.2.1
+Summary: Lightweight, extensible CLI for the-loop — quality-of-life commands the the-loop plugin can use (e.g. a GitHub webhook receiver).
+Project-URL: Homepage, https://github.com/MadaraUchiha-314/the-loop
+Project-URL: Repository, https://github.com/MadaraUchiha-314/the-loop
+Project-URL: Issues, https://github.com/MadaraUchiha-314/the-loop/issues
+Author: MadaraUchiha-314
+License: MIT
+Keywords: cli,pdlc,the-loop,webhook
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Topic :: Software Development :: Build Tools
+Requires-Python: >=3.9
+Provides-Extra: config
+Requires-Dist: pyyaml>=6; extra == 'config'
+Provides-Extra: dev
+Requires-Dist: commitizen>=3; extra == 'dev'
+Requires-Dist: pytest>=8; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# the-loop CLI
+
+A lightweight, **extensible** command-line companion to the the-loop plugin, written in
+Python (stdlib-only core — zero runtime dependencies). Python is intentional: it leaves
+room to add self-learning / ML capabilities later (mostly exposed as Python SDKs).
+
+## Install
+
+From PyPI (published as **`the-loopy-one`** — the base name `the-loop` was taken; the
+import package and CLI keep the natural `the_loop`/`the-loop`):
+
+```bash
+pip install the-loopy-one            # or: uv pip install the-loopy-one
+pip install "the-loopy-one[config]"  # + PyYAML, for reading .the-loop/config.yaml defaults
+the-loop --help
+```
+
+For local development the-loop uses **uv** (its declared Python package manager). From the
+repo root:
+
+```bash
+uv sync                     # installs the workspace (this CLI + dev tooling) from uv.lock
+uv run the-loop --help      # run the CLI
+```
+
+Or install this package on its own with any PEP 517 installer:
+
+```bash
+uv pip install -e .            # or: pip install -e .
+uv pip install -e ".[config]"  # PyYAML, for reading .the-loop/config.yaml defaults
+uv pip install -e ".[dev]"     # pytest + commitizen
+```
+
+This exposes the primary CLI: `the-loop`. Releases are **automatic**: on merge to `main`,
+`.github/workflows/release.yml` runs `cz bump` to derive the next version from the
+Conventional Commits / PR titles since the last tag (`feat` → minor, `fix` → patch,
+`BREAKING CHANGE` → major), tags it, and publishes to PyPI via Trusted Publishing (OIDC —
+no stored token). Merges with no `feat`/`fix`/breaking change publish nothing. See
+`docs/decisions/decision-019.md`.
+
+## Commands
+
+### `gh-webhook` — GitHub webhook receiver
+
+```bash
+the-loop gh-webhook start [--host 127.0.0.1] [--port 8787] [--path /gh-webhook] \
+                          [--pidfile .the-loop/gh-webhook.pid] \
+                          [--secret-env THE_LOOP_GH_WEBHOOK_SECRET] \
+                          [--route | --no-route]
+the-loop gh-webhook stop  [--pidfile .the-loop/gh-webhook.pid]
+```
+
+- Verifies the GitHub `X-Hub-Signature-256` HMAC when the secret env var is set
+  (export `THE_LOOP_GH_WEBHOOK_SECRET=...`). The secret is read from the environment,
+  never a flag, so it doesn't leak into process listings.
+- `GET /health` returns `200 ok`.
+- Defaults can come from `.the-loop/config.yaml` (`webhooks.ghWebhook`) when PyYAML is
+  installed; flags always override.
+- **`--route`** (default from `webhooks.ghWebhook.routing.enabled`) routes each verified
+  event to the registered harness session working that item: the router extracts the
+  work item(s) from the payload (issue/PR number, PR head-branch `issue-<n>` convention,
+  closing keywords, `workflow_run`/`check_*` PRs), deduplicates on `X-GitHub-Delivery`,
+  and the dispatcher resumes the matched session via its official CLI
+  (`claude -p … --resume <session-id>` / `cursor-agent -p … --resume <chat-id>`), one
+  event at a time per session, in parallel across sessions. Unmatched events follow
+  `routing.spawnOnUnmatched` (`never` drops; `always` spawns + registers a session).
+  Design: `docs/specs/issue-15/design.md`, `docs/decisions/decision-016.md`.
+
+### `sessions` — link work items to harness sessions (webhook routing)
+
+```bash
+the-loop sessions register --work-item github:OWNER/REPO#N --harness claude \
+    --harness-session-id "$CLAUDE_SESSION_ID" [--cwd .] [--force]
+the-loop sessions list  [--status active|closed] [--format table|json]
+the-loop sessions close --work-item github:OWNER/REPO#N
+```
+
+- The registry lives in `webhooks.ghWebhook.routing.registryDir` (default
+  `.the-loop/sessions/`, git-ignored) as one human-inspectable JSON file per session;
+  writes are atomic, so concurrent sessions on the same machine are safe.
+- One work item ↔ one active session; `--force` replaces a stale registration.
+- Claude Code sessions register with `$CLAUDE_SESSION_ID`; Cursor sessions register
+  with the chat id they were launched with (non-interactive `cursor-agent ls` is
+  unreliable for id discovery, so the id is captured at registration time).
+- When a work item's PR is merged or closed, the receiver **auto-closes** the session
+  (on the `pull_request` `closed` event) — no manual `sessions close` needed.
+
+**Label-gated auto-execution** (`spawnOnUnmatched: labeled`): give an issue/PR the
+configurable `routing.autoExecuteLabel` (default `the-loop: auto-execute`) and the
+receiver spawns a session and starts `/the-loop:work-on` on it — then routes that item's
+later activity (comments, reviews, CI, its linked PR) to the same session, and
+auto-closes on PR merge. Label presence is read straight from the webhook payload (no
+extra API call). A new issue *without* the label is received and ignored.
+
+### `scenarios` — query the Gherkin scenarios integration tests cover
+
+```bash
+the-loop scenarios [--root .] [--glob PATTERN ...] [--format table|markdown|json]
+```
+
+- Scans integration-test files for the Gherkin-syntax docstrings the-loop requires
+  (`Feature:` / `Scenario:` / Given-When-Then, plus an optional `Requirement:` link to a
+  `requirements.md`) and presents them as a table — so a coding-agent harness can answer
+  "what scenarios are tested?" without running anything.
+- Language-agnostic: Python docstrings, JS/TS block comments and Go comments all work.
+- Globs come from `--glob` (repeatable), else `testing.integrationTestGlobs` in
+  `.the-loop/config.yaml` (when PyYAML is installed), else built-in defaults covering
+  common layouts.
+- `--format markdown` emits a GitHub-flavoured table (for PR briefings); `--format json`
+  is machine-readable (includes each scenario's steps and `file:line`).
+
+## Adding a command (extensibility)
+
+1. Create `the_loop/commands/<your_command>.py`.
+2. Subclass `Command`, set `name`/`help`, implement `add_arguments` and `run`, and
+   decorate the class with `@register`.
+3. Import the module in `the_loop/commands/__init__.py`.
+
+The CLI discovers registered commands automatically.
+
+## Test
+
+```bash
+pytest        # from this directory
+```

the_loopy_one-0.2.1/README.md

@@ -0,0 +1,125 @@
+# the-loop CLI
+
+A lightweight, **extensible** command-line companion to the the-loop plugin, written in
+Python (stdlib-only core — zero runtime dependencies). Python is intentional: it leaves
+room to add self-learning / ML capabilities later (mostly exposed as Python SDKs).
+
+## Install
+
+From PyPI (published as **`the-loopy-one`** — the base name `the-loop` was taken; the
+import package and CLI keep the natural `the_loop`/`the-loop`):
+
+```bash
+pip install the-loopy-one            # or: uv pip install the-loopy-one
+pip install "the-loopy-one[config]"  # + PyYAML, for reading .the-loop/config.yaml defaults
+the-loop --help
+```
+
+For local development the-loop uses **uv** (its declared Python package manager). From the
+repo root:
+
+```bash
+uv sync                     # installs the workspace (this CLI + dev tooling) from uv.lock
+uv run the-loop --help      # run the CLI
+```
+
+Or install this package on its own with any PEP 517 installer:
+
+```bash
+uv pip install -e .            # or: pip install -e .
+uv pip install -e ".[config]"  # PyYAML, for reading .the-loop/config.yaml defaults
+uv pip install -e ".[dev]"     # pytest + commitizen
+```
+
+This exposes the primary CLI: `the-loop`. Releases are **automatic**: on merge to `main`,
+`.github/workflows/release.yml` runs `cz bump` to derive the next version from the
+Conventional Commits / PR titles since the last tag (`feat` → minor, `fix` → patch,
+`BREAKING CHANGE` → major), tags it, and publishes to PyPI via Trusted Publishing (OIDC —
+no stored token). Merges with no `feat`/`fix`/breaking change publish nothing. See
+`docs/decisions/decision-019.md`.
+
+## Commands
+
+### `gh-webhook` — GitHub webhook receiver
+
+```bash
+the-loop gh-webhook start [--host 127.0.0.1] [--port 8787] [--path /gh-webhook] \
+                          [--pidfile .the-loop/gh-webhook.pid] \
+                          [--secret-env THE_LOOP_GH_WEBHOOK_SECRET] \
+                          [--route | --no-route]
+the-loop gh-webhook stop  [--pidfile .the-loop/gh-webhook.pid]
+```
+
+- Verifies the GitHub `X-Hub-Signature-256` HMAC when the secret env var is set
+  (export `THE_LOOP_GH_WEBHOOK_SECRET=...`). The secret is read from the environment,
+  never a flag, so it doesn't leak into process listings.
+- `GET /health` returns `200 ok`.
+- Defaults can come from `.the-loop/config.yaml` (`webhooks.ghWebhook`) when PyYAML is
+  installed; flags always override.
+- **`--route`** (default from `webhooks.ghWebhook.routing.enabled`) routes each verified
+  event to the registered harness session working that item: the router extracts the
+  work item(s) from the payload (issue/PR number, PR head-branch `issue-<n>` convention,
+  closing keywords, `workflow_run`/`check_*` PRs), deduplicates on `X-GitHub-Delivery`,
+  and the dispatcher resumes the matched session via its official CLI
+  (`claude -p … --resume <session-id>` / `cursor-agent -p … --resume <chat-id>`), one
+  event at a time per session, in parallel across sessions. Unmatched events follow
+  `routing.spawnOnUnmatched` (`never` drops; `always` spawns + registers a session).
+  Design: `docs/specs/issue-15/design.md`, `docs/decisions/decision-016.md`.
+
+### `sessions` — link work items to harness sessions (webhook routing)
+
+```bash
+the-loop sessions register --work-item github:OWNER/REPO#N --harness claude \
+    --harness-session-id "$CLAUDE_SESSION_ID" [--cwd .] [--force]
+the-loop sessions list  [--status active|closed] [--format table|json]
+the-loop sessions close --work-item github:OWNER/REPO#N
+```
+
+- The registry lives in `webhooks.ghWebhook.routing.registryDir` (default
+  `.the-loop/sessions/`, git-ignored) as one human-inspectable JSON file per session;
+  writes are atomic, so concurrent sessions on the same machine are safe.
+- One work item ↔ one active session; `--force` replaces a stale registration.
+- Claude Code sessions register with `$CLAUDE_SESSION_ID`; Cursor sessions register
+  with the chat id they were launched with (non-interactive `cursor-agent ls` is
+  unreliable for id discovery, so the id is captured at registration time).
+- When a work item's PR is merged or closed, the receiver **auto-closes** the session
+  (on the `pull_request` `closed` event) — no manual `sessions close` needed.
+
+**Label-gated auto-execution** (`spawnOnUnmatched: labeled`): give an issue/PR the
+configurable `routing.autoExecuteLabel` (default `the-loop: auto-execute`) and the
+receiver spawns a session and starts `/the-loop:work-on` on it — then routes that item's
+later activity (comments, reviews, CI, its linked PR) to the same session, and
+auto-closes on PR merge. Label presence is read straight from the webhook payload (no
+extra API call). A new issue *without* the label is received and ignored.
+
+### `scenarios` — query the Gherkin scenarios integration tests cover
+
+```bash
+the-loop scenarios [--root .] [--glob PATTERN ...] [--format table|markdown|json]
+```
+
+- Scans integration-test files for the Gherkin-syntax docstrings the-loop requires
+  (`Feature:` / `Scenario:` / Given-When-Then, plus an optional `Requirement:` link to a
+  `requirements.md`) and presents them as a table — so a coding-agent harness can answer
+  "what scenarios are tested?" without running anything.
+- Language-agnostic: Python docstrings, JS/TS block comments and Go comments all work.
+- Globs come from `--glob` (repeatable), else `testing.integrationTestGlobs` in
+  `.the-loop/config.yaml` (when PyYAML is installed), else built-in defaults covering
+  common layouts.
+- `--format markdown` emits a GitHub-flavoured table (for PR briefings); `--format json`
+  is machine-readable (includes each scenario's steps and `file:line`).
+
+## Adding a command (extensibility)
+
+1. Create `the_loop/commands/<your_command>.py`.
+2. Subclass `Command`, set `name`/`help`, implement `add_arguments` and `run`, and
+   decorate the class with `@register`.
+3. Import the module in `the_loop/commands/__init__.py`.
+
+The CLI discovers registered commands automatically.
+
+## Test
+
+```bash
+pytest        # from this directory
+```

the_loopy_one-0.2.1/pyproject.toml

@@ -0,0 +1,56 @@
+# Three distinct names, deliberately (see docs/decisions/decision-019.md):
+#   - distribution (PyPI) name : the-loopy-one   -> `pip install the-loopy-one`
+#   - import package name      : the_loop        -> `import the_loop`
+#   - console script name      : the-loop        -> `the-loop --help`
+# The base name `the-loop` was unavailable on PyPI, so the distribution is published as
+# `the-loopy-one`; the import package and CLI keep the natural `the_loop`/`the-loop`.
+[project]
+name = "the-loopy-one"
+version = "0.2.1"
+description = "Lightweight, extensible CLI for the-loop — quality-of-life commands the the-loop plugin can use (e.g. a GitHub webhook receiver)."
+readme = "README.md"
+requires-python = ">=3.9"
+license = { text = "MIT" }
+authors = [{ name = "MadaraUchiha-314" }]
+keywords = ["the-loop", "cli", "webhook", "pdlc"]
+classifiers = [
+    "Development Status :: 3 - Alpha",
+    "Environment :: Console",
+    "Intended Audience :: Developers",
+    "License :: OSI Approved :: MIT License",
+    "Operating System :: OS Independent",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3 :: Only",
+    "Topic :: Software Development :: Build Tools",
+]
+# Core CLI has ZERO runtime dependencies (stdlib only) to stay very lightweight.
+dependencies = []
+
+[project.optional-dependencies]
+# Optional: richer config-file parsing. The CLI works without it (flags + env).
+config = ["pyyaml>=6"]
+dev = ["pytest>=8", "commitizen>=3"]
+
+[project.scripts]
+the-loop = "the_loop.__main__:main"
+
+[project.urls]
+Homepage = "https://github.com/MadaraUchiha-314/the-loop"
+Repository = "https://github.com/MadaraUchiha-314/the-loop"
+Issues = "https://github.com/MadaraUchiha-314/the-loop/issues"
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[tool.hatch.build.targets.wheel]
+packages = ["the_loop"]
+
+[tool.ruff]
+line-length = 88
+target-version = "py39"
+
+[tool.pytest.ini_options]
+# Let `pytest` find the package without an editable install (run from cli/).
+pythonpath = ["."]
+testpaths = ["tests"]

the_loopy_one-0.2.1/tests/fixtures/test_checkout_integration.py

@@ -0,0 +1,24 @@
+"""Fixture integration test used by the scenarios-extractor tests.
+
+Feature: Checkout pricing
+Requirement: docs/specs/issue-11/requirements.md#R2
+
+Scenario: Cart total includes regional tax
+    Given a cart with one $10.00 item
+    When the cart is priced in a 10% tax region
+    Then the order total is $11.00
+"""
+
+
+def test_cart_total_includes_regional_tax():
+    assert 10.00 * 1.10 == 11.0
+
+
+def test_free_shipping_over_threshold():
+    """
+    Scenario: Free shipping over the threshold
+        Given a cart subtotal of $60.00
+        When the free-shipping threshold is $50.00
+        Then shipping is $0.00
+    """
+    assert True