patch-chat 0.2.0__tar.gz → 0.3.0__tar.gz

patch_chat-0.3.0/.claude/commands/upstream-issue.md

@@ -0,0 +1,122 @@
+---
+description: Copy an upstream aider issue into this fork, fix it, ship it, and comment upstream
+argument-hint: <upstream issue URL or number>
+allowed-tools: Bash(gh:*), Bash(git:*), Bash(python:*), Bash(pytest:*), Bash(pre-commit:*), Read, Edit, Write, Grep, Glob
+---
+
+Take the upstream issue at **$ARGUMENTS** (a `Aider-AI/aider` issue URL, or a bare number meaning
+that repo) through the full pipeline below. Work top to bottom, one step at a time, and keep a
+todo list.
+
+Use the Read, Edit and Write tools for anything that reads or changes a file. Bash is for `gh`,
+`git`, `pytest` and `pre-commit` — not for `cat`, `sed` or heredocs that rewrite source.
+
+## 1. Read the upstream issue
+
+```
+gh issue view <N> --repo Aider-AI/aider --json number,title,body,author,createdAt,state,labels
+```
+
+## 2. Decide what the defect actually is
+
+This fork renames the module: upstream `aider/foo.py` is `patch/foo.py` here, the distribution is
+`patch-chat`, the CLI is `patch`. Locate the code the issue describes and confirm the behaviour
+still reproduces here — upstream and fork have diverged, and some issues are already fixed.
+
+Not every report is a code bug. A broken user environment, a provider outage or a support
+question has no fix in this repo. When that is the case, say so plainly, and look for the defect
+that *is* ours — usually how the tool presents the failure. Fix that instead, and explain the
+split in the issue body you write in step 3. Do not invent a fix for something that is not broken.
+
+If nothing here is worth changing, stop after step 3 and say why rather than closing the issue.
+
+## 3. Copy it into the fork
+
+Create the issue in `PierrunoYT/patch`, preserving the upstream title unless it names something
+this fork calls differently, and the body verbatim. Append an attribution footer:
+
+```
+---
+
+_Copied from [Aider-AI/aider#<N>](<url>) (opened by @<author> on <YYYY-MM-DD>)._
+```
+
+When your reading in step 2 differs from the reporter's — a different root cause, or the
+conclusion that the real defect is elsewhere — add a short paragraph after the footer saying so.
+That paragraph is your analysis, kept separate from their words.
+
+Label it from the repo's existing labels (`gh label list --repo PierrunoYT/patch`): always the
+kind (`bug`, `documentation`, `enhancement`, `security`), always a severity (`critical`, `high`,
+`medium`, `low`), and `good first issue` when the fix is genuinely small and self-contained.
+
+## 4. Fix it
+
+Follow the repository's own conventions in `AGENTS.md`. In short:
+
+- Make the change, and add a regression test that fails without it. Tests live in
+  `tests/basic/`, mirroring the module layout.
+- `pytest` — the whole suite, not just the new file.
+- `pre-commit run --all-files` — all five hooks. Black may reformat; re-run until clean.
+
+## 5. Update every doc the change touches — in the same pass, not as a follow-up
+
+The task is not done when the tests pass. It is done when the docs match. Go through this list
+each time and decide about each entry; the answer is often "nothing to change", but it has to be
+a decision rather than an oversight.
+
+- **`CHANGELOG.md`** — always, no exceptions. Under `## [Unreleased]`, in the right subsection
+  (`Added`, `Changed`, `Fixed`, `Removed`, `Security`). A docs-only change still gets an entry.
+  Blank line between top-level bullets; nested sub-lists stay tight. Describe what changed for
+  the reader, not which files you edited. A released `## [X.Y.Z]` section is mirrored in the git
+  tag and the GitHub release — never reword or restructure one.
+- **`README.md`** — installation, usage, supported Python or model versions, security boundaries,
+  or anything a user reads before running the tool.
+- **`CONTRIBUTING.md`** — setup, testing, dependencies, or the release process.
+- **`AGENTS.md`** — repository layout, tooling, conventions, or a trap worth recording so the
+  next agent does not rediscover it. A new module, a renamed one, or a new rule about how the
+  code is organised belongs here.
+- **Docstrings and comments next to the code you changed** — if the fix invalidates what a
+  nearby comment claims, fix the comment too.
+- **User-facing strings in the code** — `patch/args.py` help text and the messages in
+  `patch/main.py`, `patch/commands.py` and `patch/io.py` are documentation the user actually
+  reads. A changed flag or behaviour usually means one of them is now wrong.
+- **`AUDIT_REPORT.md` / `AUDIT_PROMPT.md`** — only when the fix lands on a finding those files
+  track, or rules out a candidate the prompt lists.
+
+Then grep for whatever else still describes the old behaviour
+(`grep -rn "<flag or phrase>" README.md CONTRIBUTING.md AGENTS.md patch/`). A stale doc is the
+same defect as stale code.
+
+Doc updates ship in the task's own commit (step 6), never in a later one.
+
+## 6. Commit and push
+
+One commit for the whole task — code, test and docs together. Conventional Commit subject, a body
+explaining the defect and the fix, and a trailer line:
+
+```
+Closes #<fork issue>. Reported upstream in Aider-AI/aider#<N>.
+```
+
+Push to `main`. That closes the fork issue. Confirm it did:
+
+```
+gh issue list --repo PierrunoYT/patch --state closed --limit 3
+```
+
+## 7. Comment upstream
+
+Post it without asking — invoking this command is the authorisation. Write the comment to a file
+and post it with `gh issue comment <N> --repo Aider-AI/aider --body-file <file>`. It is a public
+comment on someone else's repository under the user's account, so write it as carefully as if you
+were going to be asked to defend it: say only what step 2 actually established, and nothing the
+tests do not cover.
+
+A good comment is short and factual: confirm or correct the diagnosis, show the actual fix, say
+what the tests cover, and disclose that Patch is a fork of aider. Offer a PR when the fix would
+apply upstream unchanged. No promotion.
+
+## Report back
+
+Finish with the fork issue number, the commit SHA, the test and hook results, and the upstream
+comment link.

{patch_chat-0.2.0 → patch_chat-0.3.0}/.gitignore

@@ -20,6 +20,8 @@ patch/_version.py
 tmp.benchmarks/
 .docker_bash_history
 .amp/portals/*
-.coverage
-htmlcov/
-.coverage.*
+.coverage
+htmlcov/
+.coverage.*
+.claude/settings.json
+.claude/settings.local.json

{patch_chat-0.2.0 → patch_chat-0.3.0}/AGENTS.md

@@ -1,138 +1,200 @@
-# AGENTS.md
-
-Guidance for AI coding agents working in this repository.
-
-## What this project is
-
-Patch is an AI pair-programming tool that runs in the terminal. The Python distribution is
-[`patch-chat`](https://pypi.org/project/patch-chat/), the module is `patch/`, and the CLI entry
-point is `patch` (`patch.main:main`). Release history lives in [CHANGELOG.md](CHANGELOG.md).
-
-Versions come from git tags via setuptools-scm; the fork's own history starts at `0.1.0` and does
-not continue upstream aider's `0.86.x` numbering.
-
-## Setup
-
-Python 3.10 through 3.14 (`requires-python = ">=3.10,<3.15"`).
-
-```
-pip install -e .
-pip install -r requirements.txt
-pip install -r requirements/requirements-dev.txt
-```
-
-## Testing
-
-```
-pytest                              # full suite
-pytest tests/basic/test_coder.py    # one file
-pytest -k test_repomap              # one pattern
-```
-
-`pytest.ini` sets `testpaths` to `tests/basic`, `tests/browser` and `tests/scrape`, and forces
-`PATCH_ANALYTICS=false`. The bulk of the suite is
-the 30+ files in `tests/basic/`. `benchmark/` is excluded from collection and is
-not part of normal development.
-
-## Linting and formatting
-
-The project uses pre-commit. Run it before finishing any code change:
-
-```
-pre-commit run --all-files
-```
-
-Five hooks, all of which CI enforces:
-
-- **black**, line length 100, with `--preview`
-- **isort**, black profile
-- **flake8**, max line length 100, ignoring `E203` and `W503`
-- **mypy**, over the configured high-value module boundaries
-- **codespell**
-
-The line length is 100, not black's default 88. Match it.
-
-## Repository layout
-
-- `patch/coders/` — the heart of the project. Each edit format is a
-  `*_coder.py` paired with a `*_prompts.py` holding its system prompts.
-  `base_coder.py` (~2.6k lines) is the shared chat loop that all of them
-  subclass. `coders/usage.py` (token and cost accounting) and
-  `coders/chat_state.py` (the transcript and its background summariser)
-  hold state extracted from it. New edit formats are registered in `patch/coders/__init__.py`.
-- `patch/main.py` — CLI entry, argument wiring, startup.
-- `patch/models.py` — model definitions, aliases, and metadata. Adding support
-  for a new LLM usually means editing this file and nothing else.
-- `patch/commands.py` — the in-chat `/slash` commands.
-- `patch/repo.py`, `patch/repomap.py` — git integration and the tree-sitter
-  repository map.
-- `patch/repo_trust.py` — the repository-trust boundary. The repo under edit is
-  untrusted input, and every rule about what its config files may set lives
-  here, applied in an enforced order. Adding an argument that names a file or a
-  command means recording a decision about it in this module, or a test fails.
-- `tests/` — mirrors the module layout under `tests/basic/`.
-
-Two root-level documents cover the audit history:
-
-- `AUDIT_REPORT.md` — three completed audits (F-1 – F-97) and their remediation.
-- `AUDIT_PROMPT.md` — the reusable brief for running another one. It carries the
-  evidence bar, the recurring defect shape worth searching for, and a list of
-  candidates already investigated and rejected, so a new round does not
-  re-derive them.
-
-## Things not to edit
-
-- `patch/_version.py` — generated by setuptools_scm, gitignored.
-- `requirements/*.txt` — compiled from the matching `.in` files by
-  `./scripts/pip-compile.sh`. Edit the `.in` file and re-run the script; never
-  hand-edit the `.txt`.
-
-## CI
-
-Four workflows, all in `.github/workflows/`:
-
-- `ubuntu-tests.yml` — pytest on Python 3.10 through 3.14
-- `windows-tests.yml` — pytest on Python 3.10, 3.13
-- `pre-commit.yml` — the hooks above
-- `packaging.yml` — builds a wheel from a `.git`-less tree, installs it into a clean venv and
-  imports it from another directory. `pytest` runs from the repository root and therefore tests
-  the working tree, never the built artifact; this is the only job that does. Any new data file
-  must be added to `[tool.setuptools.package-data]` or it will fail here.
-
-Publishing and deployment workflows are intentionally absent. Do not add them without the
-required Patch-owned registries, infrastructure and secrets.
-
-## Workflow
-
-Finish each task completely before starting the next one. A task is not done when the
-code works — it is done when the docs match and the work is committed.
-
-1. Make the change and get the tests passing (`pytest`).
-2. Run `pre-commit run --all-files`. All five hooks must pass.
-3. Update every doc the change touches, in the same pass — not as a follow-up:
-   - `CHANGELOG.md` under `## [Unreleased]`, in the right subsection (`Added`,
-     `Changed`, `Fixed`, `Removed`, `Security`). This file records doc-only changes
-     too, so a docs commit still gets an entry. Describe what changed for the reader,
-     not which files were edited.
-   - `README.md` when installation, usage, security boundaries, or supported
-     versions change.
-   - `CONTRIBUTING.md` when setup, testing, dependencies, or the release process change.
-   - This file when the layout, tooling, or conventions change.
-   A released `## [X.Y.Z]` section is not a scratchpad: its text is mirrored in the annotated
-   git tag and the GitHub release, so do not reword or restructure it. Adding an entry for
-   something that genuinely shipped in that release is the one allowed edit — correcting an
-   omission is not rewriting history — and it comes with updating that release's body on
-   GitHub (`gh release edit`) in the same task. Leave the tag message alone; re-tagging a
-   published tag is worse than a tag message that trails the file.
-4. Commit the code and its doc updates together, in one commit per task. Do not
-   batch several tasks into one commit, and do not leave a task's docs for later.
-
-## Conventions
-
-- Match the surrounding style rather than importing a new one. The codebase is
-  plain Python with light comments and no type annotations in most modules.
-- Tests are a mix of `unittest.TestCase` classes (about half the files in
-  `tests/basic/`) and plain pytest functions. Follow whichever style the file
-  you are editing already uses.
-- Commits follow Conventional Commits (`feat:`, `fix:`, `docs:`, `chore:`), as
-  seen in recent history.
+# AGENTS.md
+
+Guidance for AI coding agents working in this repository.
+
+## What this project is
+
+Patch is an AI pair-programming tool that runs in the terminal. The Python distribution is
+[`patch-chat`](https://pypi.org/project/patch-chat/), the module is `patch/`, and the CLI entry
+point is `patch` (`patch.main:main`). Release history lives in [CHANGELOG.md](CHANGELOG.md).
+
+Versions come from git tags via setuptools-scm; the fork's own history starts at `0.1.0` and does
+not continue upstream aider's `0.86.x` numbering.
+
+## Setup
+
+Python 3.10 through 3.14 (`requires-python = ">=3.10,<3.15"`).
+
+```
+pip install -e .
+pip install -r requirements.txt
+pip install -r requirements/requirements-dev.txt
+```
+
+## Testing
+
+```
+pytest                              # full suite
+pytest tests/basic/test_coder.py    # one file
+pytest -k test_repomap              # one pattern
+```
+
+`pytest.ini` sets `testpaths` to `tests/basic`, `tests/browser` and `tests/scrape`, and forces
+`PATCH_ANALYTICS=false`. The bulk of the suite is
+the 30+ files in `tests/basic/`. `benchmark/` is excluded from collection and is
+not part of normal development.
+
+## Linting and formatting
+
+The project uses pre-commit. Run it before finishing any code change:
+
+```
+pre-commit run --all-files
+```
+
+Five hooks, all of which CI enforces:
+
+- **black**, line length 100, with `--preview`
+- **isort**, black profile
+- **flake8**, max line length 100, ignoring `E203` and `W503`
+- **mypy**, over the configured high-value module boundaries
+- **codespell**
+
+The line length is 100, not black's default 88. Match it.
+
+## Repository layout
+
+- `patch/coders/` — the heart of the project. Each edit format is a
+  `*_coder.py` paired with a `*_prompts.py` holding its system prompts.
+  `base_coder.py` (~2.6k lines) is the shared chat loop that all of them
+  subclass. `coders/usage.py` (token and cost accounting) and
+  `coders/chat_state.py` (the transcript and its background summariser)
+  hold state extracted from it. New edit formats are registered in `patch/coders/__init__.py`.
+- `patch/main.py` — CLI entry, argument wiring, startup.
+- `patch/models.py` — model definitions, aliases, and metadata. Adding support
+  for a new LLM usually means editing this file and nothing else.
+- `patch/commands.py` — the in-chat `/slash` commands.
+- `patch/repo.py`, `patch/repomap.py` — git integration and the tree-sitter
+  repository map.
+- `patch/repo_trust.py` — the repository-trust boundary. The repo under edit is
+  untrusted input, and every rule about what its config files may set lives
+  here, applied in an enforced order. Adding an argument that names a file or a
+  command means recording a decision about it in this module, or a test fails.
+- `tests/` — mirrors the module layout under `tests/basic/`.
+
+Two root-level documents cover the audit history:
+
+- `AUDIT_REPORT.md` — three completed audits (F-1 – F-97) and their remediation.
+- `AUDIT_PROMPT.md` — the reusable brief for running another one. It carries the
+  evidence bar, the recurring defect shape worth searching for, and a list of
+  candidates already investigated and rejected, so a new round does not
+  re-derive them.
+
+## Things not to edit
+
+- `patch/_version.py` — generated by setuptools_scm, gitignored.
+- `requirements/*.txt` — compiled from the matching `.in` files by
+  `./scripts/pip-compile.sh`. Edit the `.in` file and re-run the script; never
+  hand-edit the `.txt`.
+
+## CI
+
+Four workflows, all in `.github/workflows/`:
+
+- `ubuntu-tests.yml` — pytest on Python 3.10 through 3.14
+- `windows-tests.yml` — pytest on Python 3.10, 3.13
+- `pre-commit.yml` — the hooks above
+- `packaging.yml` — builds a wheel from a `.git`-less tree, installs it into a clean venv and
+  imports it from another directory. `pytest` runs from the repository root and therefore tests
+  the working tree, never the built artifact; this is the only job that does. Any new data file
+  must be added to `[tool.setuptools.package-data]` or it will fail here.
+
+Publishing and deployment workflows are intentionally absent. Do not add them without the
+required Patch-owned registries, infrastructure and secrets.
+
+## Workflow
+
+Finish each task completely before starting the next one. A task is not done when the
+code works — it is done when the docs match and the work is committed.
+
+1. Make the change and get the tests passing (`pytest`).
+2. Run `pre-commit run --all-files`. All five hooks must pass.
+3. Update every doc the change touches, in the same pass — not as a follow-up:
+   - `CHANGELOG.md` under `## [Unreleased]`, in the right subsection (`Added`,
+     `Changed`, `Fixed`, `Removed`, `Security`). This file records doc-only changes
+     too, so a docs commit still gets an entry. Describe what changed for the reader,
+     not which files were edited.
+   - `README.md` when installation, usage, security boundaries, or supported
+     versions change.
+   - `CONTRIBUTING.md` when setup, testing, dependencies, or the release process change.
+   - This file when the layout, tooling, or conventions change.
+   A released `## [X.Y.Z]` section is not a scratchpad: its text is mirrored in the annotated
+   git tag and the GitHub release, so do not reword or restructure it. Adding an entry for
+   something that genuinely shipped in that release is the one allowed edit — correcting an
+   omission is not rewriting history — and it comes with updating that release's body on
+   GitHub (`gh release edit`) in the same task. Leave the tag message alone; re-tagging a
+   published tag is worse than a tag message that trails the file.
+4. Commit the code and its doc updates together, in one commit per task. Do not
+   batch several tasks into one commit, and do not leave a task's docs for later.
+
+### Upstream issues
+
+Patch is a fork of [aider](https://github.com/Aider-AI/aider), and reports filed there often
+apply here. `.claude/commands/upstream-issue.md` is a Claude Code slash command
+(`/upstream-issue <url>`) that carries one from upstream to shipped: copy it into this repo's
+tracker with attribution, judge whether the defect is really ours — upstream `aider/foo.py` is
+`patch/foo.py` here, and a broken user environment has no fix in this code — write the fix and a
+regression test, update the docs above, commit with `Closes #N`, and only then comment upstream.
+Editing that file is how the procedure changes; do not keep a second copy of it here.
+
+## Releases
+
+The full steps are in `CONTRIBUTING.md` under "Making a Release". Read them before cutting one;
+the traps below have each cost a rebuild.
+
+- **The version comes from the git tag, nothing else.** `patch/__init__.py`'s `safe_version` and
+  `pyproject.toml`'s `fallback_version` are floors, not the version. Bumping them without tagging
+  makes every run report `X.Y.Z.dev+less`, because the generated `patch/_version.py` left over
+  from the previous build is now below the new floor. Tagging and rebuilding clears it.
+- **Tag with `--cleanup=verbatim`.** `git tag -F` otherwise defaults to `--cleanup=strip` and
+  deletes every line beginning with `#`, silently removing the `##` title and all the `###`
+  headings from a changelog section used as the tag message. Both `v0.1.0` and `v0.2.0` were
+  tagged without it, so their tag messages are flattened; the release bodies are fine, because
+  both were published with `--notes-file` from the changelog rather than from the tag.
+- **Reuse the notes file for `gh release create --notes-file`.** Write the changelog section to a
+  file in step 2 and pass that same path in step 4. Never spell it as a `<placeholder>`: in
+  PowerShell, the default shell here, `<` is a reserved operator and the command fails to parse
+  before `gh` runs.
+- **Re-tag only while the tag is local.** If a later commit changes the changelog section, delete
+  the tag, re-tag on the new HEAD, and rebuild — the artifacts must come from the tagged commit.
+  Once the tag is pushed this is closed off; see the rule in Workflow step 3.
+- **Verify the artifact, not the checkout.** Install the built wheel into a venv outside the
+  repository and check `patch --version` plus the bundled data files
+  (`resources/model-settings.yml`, `queries/**/*.scm`). From the repository root `tests/__init__.py`
+  puts the working tree on `sys.path`, so an in-tree import proves nothing about the wheel.
+
+## Conventions
+
+- Match the surrounding style rather than importing a new one. The codebase is
+  plain Python with light comments and no type annotations in most modules.
+- Tests are a mix of `unittest.TestCase` classes (about half the files in
+  `tests/basic/`) and plain pytest functions. Follow whichever style the file
+  you are editing already uses.
+- Commits follow Conventional Commits (`feat:`, `fix:`, `docs:`, `chore:`), as
+  seen in recent history.
+- Separate every top-level `CHANGELOG.md` bullet with a blank line. CommonMark makes a list
+  *loose* -- each item wrapped in `<p>`, with paragraph margins -- as soon as any two of its items
+  are separated by a blank line, and *tight* otherwise. One stray blank line therefore respaces a
+  whole section, so a file mixing the two renders on GitHub with some sections airy and others
+  dense. Entries here are multi-sentence, so loose is the target. Nested sub-lists stay tight.
+- Anything passed to `analytics.event(...)` leaves the machine. `Analytics.event` scrubs every
+  property -- URL query strings, absolute paths, length -- so a call site cannot leak by
+  forgetting, but the scrubber only removes shapes it knows. Send a class name, a fixed reason or
+  a count; never `str(err)`, never free text from a remote server, and route a model name through
+  `redact_model_name`. The opt-in prompt in `patch/main.py` is a promise about this.
+- A new `raise SwitchCoder(...)` has to say whether the user's message was already carried out
+  before the switch. `/ask PROMPT` answers on a temporary coder and then switches back, so it
+  passes `message_handled=True`; `/model` switches instead of doing anything, and leaves the
+  default. `run_one_message` in `patch/main.py` uses that to decide whether a one-shot
+  `--message` run lost the user's request or completed it.
+- A chat message's `content` is not always a string. An assistant reply that is only a function
+  call carries `content=None`, and a message carrying an image carries a list of parts. Read the
+  words with `patch.utils.message_content_text(msg)`; concatenating `msg["content"]` raises
+  `TypeError` on an ordinary conversation.
+- Write to the terminal through `InputOutput._console_print`, never `self.console.print`
+  directly. A terminal write can fail on its own — a legacy Windows console rejects some writes
+  with `OSError: [Errno 22]`, and a closed or redirected handle raises too — and most callers are
+  reporting an error already, so an escaping `OSError` replaces the message with a traceback and
+  ends the session. `_console_print` degrades to ASCII, then to a plain `print`, then to silence.
+  The exception is a `Console(file=StringIO())` used to format a string, which never touches a
+  terminal.

{patch_chat-0.2.0 → patch_chat-0.3.0}/AUDIT_REPORT.md

@@ -274,6 +274,16 @@ Reject in `allowed_to_edit` and in `patch_coder`'s `move_path` (see F-8).
   `.env` supplying a key is a common legitimate workflow and is not the exfiltration primitive; the
   endpoint redirect is, and that is blocked.
 
+  **Revised** while porting `Aider-AI/aider#5622`. The narrowing above was half right: supplying a
+  key is a legitimate workflow, but *replacing* the user's own key is a second exfiltration
+  primitive, not a lesser version of the first. A repository shipping `OPENAI_API_KEY=sk-attacker`
+  sends the victim's prompts to the real provider on the attacker's account, where the attacker can
+  read them — no fake endpoint required, and nothing on the denylist touches it. An untrusted
+  repository `.env` now applies only to variables the inherited environment does not already define,
+  and reports the ones it left alone. The legitimate workflow is unaffected, because a project key
+  still applies when the user has not set one; `override=False` for the user's own files was *not*
+  adopted, since naming `--env-file` on the command line is an instruction rather than a surprise.
+
   Opt back in with `--trust-repo-config` / `PATCH_TRUST_REPO_CONFIG`, accepted only from the command
   line or the ambient shell environment — both read before the repository `.env` is loaded — and
   `trust-repo-config` is itself on the blocked list, so a repository cannot self-grant from either