@aarushpandey/gitagent 1.0.0

package/examples/sample-review-tqec-pr894-v1-raw-flawed.md

@@ -0,0 +1,71 @@
+# ⚠️ FLAWED OUTPUT — kept as a teaching artifact
+
+This file is the **raw output of an earlier version of the review copilot
+prompt**. Multiple findings turned out to be factually wrong when verified
+against pytest and pytest-timeout source.
+
+**Do not use this as a model of the tool's current behavior.** It exists in
+the repo to document:
+- what hallucination from a code-review LLM actually looks like in practice;
+- why we then hardened the system prompt (see `src/prompts/review.js` rule set
+  starting "Anti-hallucination rules");
+- why the maintainer-facing workflow includes a manual curation step.
+
+## What was wrong with this v1 review (verified against source)
+
+| Original claim | Reality |
+|---|---|
+| "Silent no-op if `pytest-timeout` is not installed" | `tqec/pyproject.toml` pins `pytest-timeout>=2.4.0`. The plugin is always installed. The reviewer didn't have `pyproject.toml` in context — fixed in v2 by also fetching dependency manifests. |
+| "If `pytest-timeout` iterates in reverse … slow tests could silently receive the wrong timeout" | Per pytest source, `get_closest_marker` returns the first marker yielded by `iter_markers`. For function-level markers in `own_markers`, that's the first one added. The behavior is deterministic, not version-dependent. |
+| "Tests with an explicit `@pytest.mark.timeout(N)` will have their timeout overridden by the conftest" | **Backwards.** Because the conftest *appends* (`add_marker(append=True)`) and `get_closest_marker` returns the *first* matching marker, an existing decorator wins. The conftest's marker is silently ignored when an explicit one exists. |
+| "If CI passes `--timeout=X` on the command line, that takes precedence over marker-based timeouts" | **Wrong direction.** Per [pytest-timeout docs](https://pypi.org/project/pytest-timeout/) the documented precedence (low → high) is: config → env var → CLI `--timeout` → marker. Markers outrank CLI. |
+
+The improved-prompt output is in `sample-review-tqec-pr894-v2-raw.md`. The
+human-curated final reviewer notes are in `sample-review-tqec-pr894-v3-curated.md`.
+
+---
+
+# Original v1 raw output (DO NOT TRUST)
+
+## 1. Bug Risk
+
+**Marker ordering / override risk (`tests/conftest.py:9-10`)**
+
+`item.add_marker(pytest.mark.timeout(SLOW_TEST_TIMEOUT))` appends the marker. When `pytest-timeout` resolves the effective timeout for a test item it looks for the *first* matching marker (highest priority). If a specific test already carries its own `@pytest.mark.timeout(N)` annotation, the conftest-added marker will be appended *after* that one, which is actually correct behavior for most pytest-timeout versions (first marker wins). However, if `pytest-timeout` iterates in reverse or any future version changes precedence, slow tests could silently receive the wrong timeout. There is no guard against double-application.
+
+**No `append` kwarg specified (`tests/conftest.py:10`)**
+
+`add_marker` defaults to `append=True` in modern pytest, but making this explicit (`item.add_marker(..., append=True)`) documents intent and prevents a surprise if the default ever changes.
+
+**Silent no-op if `pytest-timeout` is not installed (`tests/conftest.py:10`)**
+
+The hook happily adds a `timeout` marker regardless of whether `pytest-timeout` is installed. If the plugin is absent, the marker is ignored without warning. There is no `pytest.importorskip` or requirements check to surface this misconfiguration.
+
+**Drift from issue intent**: The issue says the *default* timeout is 30 s. That default appears to come from a `pyproject.toml`/`pytest.ini` `timeout =` setting (not visible in this diff). The conftest only increases timeouts for slow tests; it does not verify or document what the baseline is. If that baseline setting is ever removed, slow tests would get 300 s but fast tests would get *no* timeout at all — silently.
+
+## 2. Edge Cases
+
+- **Test already marked with `@pytest.mark.timeout`**: A developer who decorates a slow test with a custom timeout (e.g., 600 s for a particularly heavy test) will now have *two* timeout markers. Behavior depends entirely on `pytest-timeout` internals (which marker takes precedence). The conftest should check for an existing `timeout` marker before adding one.
+- **Nested/parametrized slow tests**: `get_closest_marker("slow")` works correctly for parametrized items and inherited class-level markers, so this is low risk, but worth confirming if the test suite uses class-based tests.
+- **`SLOW_TEST_TIMEOUT = 300` hardcoded**: 300 s (5 min) may be too short for some future slow tests and too long for others. Consider making this configurable via a `pytest.ini` option or environment variable.
+- **`--timeout` CLI override interaction**: If CI passes `--timeout=X` on the command line, that takes precedence over marker-based timeouts in some `pytest-timeout` versions, making the conftest logic a no-op in those environments without warning.
+
+## 3. Test Coverage
+
+There is no test verifying that the hook correctly applies the marker. Conftest hooks are notoriously easy to accidentally break (e.g., a rename of `get_closest_marker` in a future pytest version). A meta-test (e.g., using `pytester`/`testdir` fixtures) that:
+
+1. Defines a dummy slow test,
+2. Runs collection via the conftest hook,
+3. Asserts the `timeout` marker is present with value `300`,
+
+would lock in the intended behavior. The absence of such a test means a silent regression is possible.
+
+## 4. Scope Creep
+
+None detected. The diff is minimal and directly addresses the stated issue. Only `tests/conftest.py` is touched.
+
+## 5. Verdict
+
+**NEEDS_DISCUSSION**
+
+The implementation is directionally correct but has two issues worth resolving before merge: (1) there is no guard against double-application when a slow test already carries an explicit `timeout` marker, which can produce surprising behavior depending on `pytest-timeout` version; and (2) the interaction with the global `timeout` baseline (presumably set elsewhere) is undocumented and fragile — removing that baseline setting would silently disable timeouts for all non-slow tests. These are not outright blockers but represent enough ambiguity in intended behavior that a brief discussion (or at minimum inline comments documenting the assumptions) is warranted before approval.

package/examples/sample-review-tqec-pr894-v2-raw.md

@@ -0,0 +1,48 @@
+# Raw output — improved-prompt v2
+
+This is the unedited output of the review copilot **after** the prompt was
+hardened with explicit anti-hallucination rules and the pipeline was changed
+to also fetch dependency manifests (`pyproject.toml`, `package.json`, …)
+into review context.
+
+Compare against `sample-review-tqec-pr894-v1-raw-flawed.md` to see what the
+prompt-level fixes change in practice. Notice this version:
+
+- Does **not** claim `pytest-timeout` might be missing (it now sees `pyproject.toml` and could verify).
+- Does **not** assert pytest-timeout precedence as fact — it explicitly hedges *"I am not certain of the precedence rules…please confirm"*.
+- Recommends a concrete fix that sidesteps the precedence ambiguity entirely (`if not item.get_closest_marker("timeout")`).
+
+The human-curated final version (with citations to pytest source that *answer*
+the questions this review hedges on) is `sample-review-tqec-pr894-v3-curated.md`.
+
+---
+
+## 1. Bug Risk
+
+**Marker append order — potential timeout override (speculation, requires library confirmation):**
+
+`tests/conftest.py:9-10` — The code calls `item.add_marker(pytest.mark.timeout(SLOW_TEST_TIMEOUT))` to append a `timeout` marker to items that already carry a `slow` marker. `pytest-timeout` resolves which `timeout` marker to honor when multiple are present on a single test item. I am not certain of the precedence rules for `pytest-timeout` when multiple `timeout` markers exist; please confirm against its docs or source. If `pytest-timeout` uses the *first* marker it finds rather than the *last*, and tests already have an explicit `@pytest.mark.timeout(...)` decorator, the appended marker may lose. Conversely, if a slow test has an explicit `@pytest.mark.timeout(60)`, this code will also append the 300-second marker, which may override the intentional shorter timeout. The safer call, if the library supports it, would be `item.add_marker(..., append=False)` (prepend) or — better — to check whether a `timeout` marker already exists before adding one.
+
+**No drift from the issue's stated intent.** The PR does what the issue asks: uses `conftest.py` to set a higher timeout for `slow`-marked tests.
+
+## 2. Edge Cases
+
+**Tests with an explicit, shorter `timeout` marker:** If any slow test already has `@pytest.mark.timeout(N)` for some `N < 300`, this hook unconditionally appends a second `timeout` marker (`conftest.py:10`). The effective timeout will depend on `pytest-timeout`'s multi-marker behavior (unknown from this context). A guard like `if not item.get_closest_marker("timeout"):` would make the intent explicit and avoid surprises.
+
+**`config` parameter omission:** `pytest_collection_modifyitems` accepts an optional `config` parameter (`def pytest_collection_modifyitems(config, items)`). Omitting it is valid in pytest, so this is not a bug — just noting it is intentional or irrelevant here.
+
+**`SLOW_TEST_TIMEOUT = 300` with no documentation of rationale:** 5 minutes is a reasonable heuristic, but there is no comment explaining why 300 was chosen or whether it was validated against actual slow-test durations. This is a nit, not a blocker.
+
+## 3. Test Coverage
+
+There are no tests for the `conftest.py` hook itself. For a conftest hook this is standard practice — testing pytest hooks in isolation is unusual and generally not expected. The correctness of the hook can be validated by running `pytest -m slow` and observing that the timeout is applied. No gap to flag here beyond the speculative multi-marker concern above.
+
+## 4. Scope Creep
+
+No scope creep. The diff is a single new file (`tests/conftest.py`) that directly implements what the issue requested. No unrelated changes are bundled.
+
+## 5. Verdict
+
+**NEEDS_DISCUSSION**
+
+The implementation is minimal and correctly structured, but there is one unresolved question that warrants discussion before merging: `pytest-timeout`'s behavior when multiple `timeout` markers exist on the same test item is not confirmed from the available context. If it honors the *last*-added marker (append wins), the code works as intended for the common case but will silently override any intentional explicit-timeout annotation on a slow test. If it honors the *first* marker, the appended marker is a no-op for tests that already carry a `timeout`. Adding a guard — `if not item.get_closest_marker("timeout"): item.add_marker(...)` — would make the behavior unambiguous regardless of library internals and is a low-cost change. The team should confirm the intended interaction with tests that carry both `slow` and an explicit `timeout` marker before merging.

package/examples/sample-review-tqec-pr894-v3-curated.md

@@ -0,0 +1,118 @@
+# Curated review — `tqec/tqec` PR #894
+
+This is the human-curated review of [PR #894](https://github.com/tqec/tqec/pull/894),
+distilled from the v2 raw output (`sample-review-tqec-pr894-v2-raw.md`)
+after verifying every behavioural claim against pytest and pytest-timeout
+source.
+
+The agent's raw v2 output had to hedge on pytest-timeout's multi-marker
+precedence because the library docs don't address it. Looking at pytest source
+resolves the ambiguity — and the resolution is **less alarming** than the v1
+raw output suggested. This version answers the question rather than
+speculating about it.
+
+---
+
+## Verdict: NEEDS_DISCUSSION
+
+Not blocking. One concrete behavioural footgun is worth a brief discussion or
+a one-line guard before merging.
+
+## What works
+
+- **The diff is minimal and faithful to the issue.** A single new file
+  `tests/conftest.py`, no unrelated changes, behaviour scoped to tests
+  carrying the `slow` marker.
+- **The dependency is real.** `pyproject.toml` pins
+  `pytest-timeout>=2.4.0` under the `test` extra, and the `slow` marker is
+  registered in `[tool.pytest.ini_options]`. No "what if it's not installed"
+  concern applies here.
+
+## One subtle behavioural footgun
+
+When a slow test **also** carries an explicit `@pytest.mark.timeout(N)`
+decorator, the conftest's appended marker is silently ignored — the original
+decorator wins. Whether this is desirable depends on author intent:
+
+- A developer who writes `@pytest.mark.timeout(900)` on a particularly heavy
+  slow test (because they know 300 s is too short) **gets the behaviour they
+  expected**: their 900 is preserved.
+- A developer who writes `@pytest.mark.timeout(60)` on a slow test (perhaps
+  for debugging, perhaps by accident) **does not get the conftest's 300 s
+  bump** — they get 60 s and the slow test fails inside their explicit cap.
+
+### Why this is the actual behaviour, with citations and a runtime check
+
+The claim that the explicit decorator wins is verified two ways:
+
+1. **From source.** The chain of citations below explains why.
+2. **At runtime.** [`verify-marker-precedence/`](verify-marker-precedence/)
+   in this repo is a self-contained 4-file pytest project that uses the
+   exact `conftest.py` from PR #894, defines the three relevant test
+   configurations (slow + explicit-timeout(1), slow only, no markers), and
+   prints what `get_closest_marker("timeout")` resolves to for each test
+   without executing them. Reproducible in 30 seconds with `pip install
+   pytest pytest-timeout && python verify_precedence.py`. Recorded output
+   shows the test with both markers resolves to the explicit `(1,)`.
+
+
+
+`add_marker(marker, append: bool = True) -> None` ([pytest source][1]) — the
+default is `append=True`, so the conftest's marker lands at the **end** of
+the item's `own_markers` list.
+
+`pytest-timeout`'s `_get_item_settings` calls
+`item.get_closest_marker("timeout")` ([pytest-timeout source][2]). pytest's
+`get_closest_marker` returns `next(self.iter_markers(name=name), default)`
+([pytest source][3]). For markers on the same node, `iter_markers` yields them
+in the order they were added to `own_markers`, so the explicit decorator —
+which was applied at collection time, before this hook runs — comes first
+and wins.
+
+[1]: https://github.com/pytest-dev/pytest/blob/main/src/_pytest/nodes.py
+[2]: https://github.com/pytest-dev/pytest-timeout/blob/master/pytest_timeout.py
+[3]: https://github.com/pytest-dev/pytest/blob/main/src/_pytest/nodes.py
+
+### Suggested fix
+
+Make the intent explicit by guarding on existing timeout markers:
+
+```python
+def pytest_collection_modifyitems(items):
+    """Increase timeouts for tests marked as slow, unless the test has its
+    own explicit timeout marker (which we leave alone)."""
+    for item in items:
+        if item.get_closest_marker("slow") and not item.get_closest_marker("timeout"):
+            item.add_marker(pytest.mark.timeout(SLOW_TEST_TIMEOUT))
+```
+
+This is mechanically equivalent to today's behaviour (because the existing
+decorator would win anyway) but makes the precedence visible at the call site,
+removes any reader confusion about which marker takes effect, and avoids any
+dependency on a future pytest-timeout change to multi-marker resolution.
+
+## Coupling worth a comment
+
+The diff increases timeouts only for `slow` tests. The 30 s baseline for
+non-slow tests comes from `[tool.pytest.ini_options] timeout = 30` in
+`pyproject.toml`, which lives outside this diff. If anyone ever removes that
+line, fast tests silently lose all timeouts. A two-line comment in
+`conftest.py` pointing at the pyproject setting would make the coupling
+discoverable for future maintainers — not a blocker, just a courtesy to the
+next person debugging a runaway test.
+
+---
+
+## What was cut from the raw v2 output, and why
+
+| Cut | Reason |
+|---|---|
+| "Marker ordering / first-vs-last" hedge | Resolved with the citations above. The behaviour is deterministic. |
+| "Make `append=True` explicit" | Style nit; default is documented. |
+| "`config` parameter omission" | The raw output already noted this is not a bug. Removed to reduce noise. |
+| "`SLOW_TEST_TIMEOUT = 300` lacks rationale comment" | True but inconsequential. A heuristic doesn't need defence. |
+| "Missing meta-test" | The raw v2 already softened this from v1's "valid nit" to "testing pytest hooks in isolation is unusual" — fully cut here for the same reason. |
+
+What's left is **two findings**: one concrete actionable suggestion (the guard)
+and one documentation nudge (the comment about the pyproject baseline). That's
+the maintainer-facing version.

package/examples/verify-marker-precedence/README.md

@@ -0,0 +1,97 @@
+# Marker-precedence empirical verification
+
+Self-contained pytest project that runtime-verifies the central behavioral
+claim in [`../sample-review-tqec-pr894-v3-curated.md`](../sample-review-tqec-pr894-v3-curated.md):
+
+> When a slow test also carries an explicit `@pytest.mark.timeout(N)`
+> decorator, the conftest's appended marker is silently ignored — the
+> original decorator wins.
+
+The curated review derives this from reading pytest and pytest-timeout
+source code. This directory makes it observable at runtime.
+
+## Files
+
+| File | Role |
+|---|---|
+| `conftest.py` | Verbatim copy (modulo formatting) of `tests/conftest.py` from [`tqec/tqec` PR #894](https://github.com/tqec/tqec/pull/894). |
+| `pyproject.toml` | Registers the `slow` marker so pytest doesn't warn about an unknown marker. Deliberately omits the `timeout = 30` baseline that lives in tqec's pyproject — we only want to test the marker-vs-marker interaction. |
+| `test_marker_precedence.py` | Three test cases probing the three relevant configurations: `slow + explicit-timeout(1)`, `slow only`, `no markers`. |
+| `verify_precedence.py` | Plugin-based inspector that runs `pytest --collect-only` with a hook that prints the resolved timeout marker for each item. **No tests are actually executed** — sidesteps platform-dependent pytest-timeout behavior. |
+
+## How to reproduce
+
+```bash
+pip install pytest pytest-timeout         # tested with 8.3.5 / 2.4.0
+cd examples/verify-marker-precedence
+python verify_precedence.py
+```
+
+## Recorded output
+
+Run on `pytest 8.3.5 + pytest-timeout 2.4.0` (Python 3.8.0, Windows):
+
+```
+test_marker_precedence.py::test_explicit_short_timeout_should_win
+test_marker_precedence.py::test_only_slow_marker_uses_conftest_timeout
+test_marker_precedence.py::test_no_markers_unaffected
+
+================================================================
+Marker precedence inspection (no tests executed)
+================================================================
+
+test_marker_precedence.py::test_explicit_short_timeout_should_win
+  all timeout markers found: [(1,), (300,)]
+  effective (get_closest_marker): (1,)
+
+test_marker_precedence.py::test_only_slow_marker_uses_conftest_timeout
+  all timeout markers found: [(300,)]
+  effective (get_closest_marker): (300,)
+
+test_marker_precedence.py::test_no_markers_unaffected
+  all timeout markers found: []
+  effective (get_closest_marker): None
+
+
+3 tests collected in 0.00s
+```
+
+## Reading the result
+
+The first test has **both** timeout markers attached to its item — `(1,)` was
+applied during decoration (module load), `(300,)` was appended by the
+conftest's `pytest_collection_modifyitems` hook after collection. Both are
+visible via `iter_markers`.
+
+`get_closest_marker("timeout")` returns the **first** one (`(1,)`), because
+within the same node's `own_markers` list, that's the iteration order. The
+explicit decorator wins; the conftest's marker is shadowed.
+
+This is the runtime-observable consequence of the citation chain in
+v3-curated.md:
+
+1. `add_marker(marker, append=True)` (default) appends to `own_markers`.
+   ([pytest source][1])
+2. `iter_markers(name=...)` yields markers from `own_markers` in order.
+   ([pytest source][1])
+3. `get_closest_marker(...)` returns `next(iter_markers(...), default)`.
+   ([pytest source][1])
+4. pytest-timeout reads exactly that. ([pytest-timeout source][2])
+
+[1]: https://github.com/pytest-dev/pytest/blob/main/src/_pytest/nodes.py
+[2]: https://github.com/pytest-dev/pytest-timeout/blob/master/pytest_timeout.py
+
+## Why this matters for the v3-curated review
+
+The recommended fix in the curated review —
+
+```python
+if item.get_closest_marker("slow") and not item.get_closest_marker("timeout"):
+    item.add_marker(pytest.mark.timeout(SLOW_TEST_TIMEOUT))
+```
+
+— is **mechanically equivalent** to today's behaviour for tests with an
+explicit timeout, because the explicit one already wins. It's a clarity
+nudge, not a bug fix. The recorded output above is what makes that claim
+checkable: every reviewer can re-run this script in 30 seconds and see
+which marker wins.

package/examples/verify-marker-precedence/conftest.py

@@ -0,0 +1,15 @@
+# Mirror of tests/conftest.py from tqec/tqec PR #894 — kept here verbatim
+# (modulo formatting) so the empirical test in this directory exercises the
+# exact behavior under review.
+#
+# Source: https://github.com/tqec/tqec/pull/894/files
+import pytest
+
+SLOW_TEST_TIMEOUT = 300
+
+
+def pytest_collection_modifyitems(items):
+    """Increase timeouts for tests marked as slow."""
+    for item in items:
+        if item.get_closest_marker("slow"):
+            item.add_marker(pytest.mark.timeout(SLOW_TEST_TIMEOUT))

package/examples/verify-marker-precedence/pyproject.toml

@@ -0,0 +1,8 @@
+[tool.pytest.ini_options]
+markers = [
+    "slow: mark a test that takes a long time to run.",
+]
+# We DO NOT set `timeout = 30` here, unlike tqec's pyproject.toml — the only
+# thing this minimal repo is testing is whether the conftest's appended marker
+# overrides an explicit @pytest.mark.timeout decorator. Adding a baseline would
+# add a second variable.

package/examples/verify-marker-precedence/test_marker_precedence.py

@@ -0,0 +1,56 @@
+"""
+Empirical verification of the marker-precedence claim made in
+`examples/sample-review-tqec-pr894-v3-curated.md`.
+
+The curated review claims:
+
+    When a slow test also carries an explicit @pytest.mark.timeout(N)
+    decorator, the conftest's appended marker is silently ignored — the
+    original decorator wins.
+
+This file proves that runtime, not just from source-reading.
+
+Three tests:
+
+1. test_explicit_short_timeout_should_win
+   Has @pytest.mark.slow AND @pytest.mark.timeout(1). Sleeps 2 seconds.
+   - If the explicit 1s decorator wins → this test FAILS with a Timeout.
+   - If the conftest's appended 300s wins → this test PASSES.
+
+2. test_only_slow_marker_uses_conftest_timeout
+   Has only @pytest.mark.slow, sleeps 2 seconds. Should always pass:
+   conftest's 300s applies, 2 < 300.
+
+3. test_no_markers_unaffected
+   Bare test. No timeout marker. No conftest hook applies. Passes trivially.
+
+Expected outcome on POSIX (Linux/macOS): 1 failed (timeouted), 2 passed.
+The failed test is the proof that the explicit decorator survives the hook.
+
+Expected outcome on Windows: pytest-timeout's default `--timeout-method=thread`
+hard-terminates the process via os._exit(1) on the first timeout, so tests 2
+and 3 may never report. For a deterministic transcript on every platform, run
+`python verify_precedence.py` instead — it inspects the resolved markers via
+--collect-only and never executes the test bodies.
+"""
+import time
+
+import pytest
+
+
+@pytest.mark.slow
+@pytest.mark.timeout(1)
+def test_explicit_short_timeout_should_win() -> None:
+    """Sleep 2s. Times out at 1s if the explicit decorator wins."""
+    time.sleep(2)
+
+
+@pytest.mark.slow
+def test_only_slow_marker_uses_conftest_timeout() -> None:
+    """No explicit timeout — conftest's 300s applies, 2s sleep passes."""
+    time.sleep(2)
+
+
+def test_no_markers_unaffected() -> None:
+    """Bare test, conftest hook does nothing for it."""
+    assert True

package/examples/verify-marker-precedence/verify_precedence.py

@@ -0,0 +1,67 @@
+"""
+Inspect — without executing — which @pytest.mark.timeout marker each test
+resolves to under the conftest.py from tqec/tqec PR #894.
+
+This sidesteps the platform-dependent run-time behavior of pytest-timeout
+(thread-method on Windows hard-terminates the process, masking the summary).
+By using --collect-only and inspecting the marker structure directly, we get
+a deterministic transcript that any reviewer can reproduce.
+
+Run it with:
+
+    python verify_precedence.py
+
+Expected output (verified on pytest 8.3.5 + pytest-timeout 2.4.0):
+
+    test_marker_precedence.py::test_explicit_short_timeout_should_win
+      all timeout markers found: [(1,), (300,)]
+      effective (get_closest_marker): (1,)
+    test_marker_precedence.py::test_only_slow_marker_uses_conftest_timeout
+      all timeout markers found: [(300,)]
+      effective (get_closest_marker): (300,)
+    test_marker_precedence.py::test_no_markers_unaffected
+      all timeout markers found: []
+      effective (get_closest_marker): None
+
+Reading: when both an explicit @pytest.mark.timeout(1) decorator AND the
+conftest's appended @pytest.mark.timeout(300) are present, get_closest_marker
+returns the (1,) marker — the explicit decorator wins, the appended marker
+is silently shadowed. This empirically confirms the citation chain in
+sample-review-tqec-pr894-v3-curated.md.
+"""
+
+import sys
+
+import pytest
+
+
+class MarkerInspector:
+    """Pytest plugin that prints the resolved timeout marker for each item
+    after collection, then lets the run end (via --collect-only)."""
+
+    def pytest_collection_finish(self, session):  # noqa: D401
+        print()
+        print("=" * 64)
+        print("Marker precedence inspection (no tests executed)")
+        print("=" * 64)
+        for item in session.items:
+            timeout_markers = [m.args for m in item.iter_markers(name="timeout")]
+            closest = item.get_closest_marker("timeout")
+            effective = closest.args if closest else None
+            print(f"\n{item.nodeid}")
+            print(f"  all timeout markers found: {timeout_markers}")
+            print(f"  effective (get_closest_marker): {effective}")
+        print()
+
+
+if __name__ == "__main__":
+    sys.exit(
+        pytest.main(
+            [
+                "--collect-only",
+                "-q",
+                "test_marker_precedence.py",
+            ],
+            plugins=[MarkerInspector()],
+        )
+    )

package/examples/workflows/issue-fix.yml

@@ -0,0 +1,32 @@
+# Auto-fix issues with github-agent: label an issue `agent-fix` and the agent
+# clones the repo, writes a patch, self-reviews it, and opens a PR.
+#
+# Copy this into your repo at .github/workflows/issue-fix.yml and add an
+# ANTHROPIC_API_KEY secret. The built-in GITHUB_TOKEN handles the PR.
+#
+# Safety: the agent only runs when a maintainer applies the `agent-fix` label,
+# so random issue authors can't trigger paid runs. The pipeline's own PR gate
+# still refuses to open a PR on a failed self-review.
+name: Issue fix (github-agent)
+
+on:
+  issues:
+    types: [labeled]
+
+permissions:
+  contents: write
+  issues: write
+  pull-requests: write
+
+jobs:
+  fix:
+    if: github.event.label.name == 'agent-fix'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Engineer a fix and open a PR
+        uses: Hadar01/github-agents@v1
+        with:
+          command: issue
+          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
+          comment: 'true'        # link the PR back on the issue
+          max-cost: '2.50'

package/examples/workflows/pr-review.yml

@@ -0,0 +1,34 @@
+# Auto-review every pull request with github-agent.
+#
+# Copy this file into your repo at .github/workflows/pr-review.yml and add an
+# ANTHROPIC_API_KEY secret (Settings → Secrets and variables → Actions).
+#
+# Why pull_request_target instead of pull_request:
+#   github-agent reviews a PR by fetching its diff through the GitHub API and
+#   sending it to Claude — it never checks out or executes the PR's code. That
+#   makes pull_request_target safe here, and it is what lets reviews on PRs from
+#   forks read the ANTHROPIC_API_KEY secret (plain pull_request cannot).
+name: PR review (github-agent)
+
+on:
+  pull_request_target:
+    types: [opened, synchronize, reopened]
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Review the pull request
+        uses: Hadar01/github-agents@v1
+        with:
+          command: review
+          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
+          post: 'true'
+          # Advisory by default: posts findings, never blocks merge.
+          # Flip to 'true' to make REQUEST_CHANGES fail the check (a merge gate).
+          fail-on-request-changes: 'false'
+          max-cost: '1.50'

package/package.json

@@ -0,0 +1,75 @@
+{
+  "name": "@aarushpandey/gitagent",
+  "version": "1.0.0",
+  "publishConfig": {
+    "access": "public"
+  },
+  "description": "Autonomous GitHub engineering pipeline: takes an issue, ships a PR, and reviews its own diff before opening it.",
+  "main": "src/pipeline.js",
+  "bin": {
+    "github-agent": "src/pipeline.js"
+  },
+  "scripts": {
+    "test": "jest",
+    "issue": "node src/pipeline.js issue",
+    "review": "node src/pipeline.js review",
+    "triage": "node src/pipeline.js triage",
+    "verify": "node scripts/verify.js",
+    "smoke": "node -e \"const p = require('./src/pipeline.js'); if (typeof p.buildAuditTrail !== 'function') process.exit(1); console.log('ok');\"",
+    "prepublishOnly": "npm test"
+  },
+  "keywords": [
+    "ai",
+    "agent",
+    "claude",
+    "anthropic",
+    "github",
+    "automation",
+    "code-review",
+    "pull-request",
+    "engineering-agent",
+    "autonomous"
+  ],
+  "author": "Hadar01",
+  "license": "MIT",
+  "homepage": "https://github.com/Hadar01/github-agents#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Hadar01/github-agents.git"
+  },
+  "bugs": {
+    "url": "https://github.com/Hadar01/github-agents/issues"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "files": [
+    "src/",
+    "scripts/",
+    "examples/",
+    "action.yml",
+    "README.md",
+    "LICENSE",
+    "CONTRIBUTING.md",
+    "TESTING.md"
+  ],
+  "dependencies": {
+    "@anthropic-ai/sdk": "^0.90.0",
+    "@octokit/rest": "^22.0.1",
+    "dotenv": "^17.4.2",
+    "express": "^5.2.1",
+    "simple-git": "^3.36.0"
+  },
+  "devDependencies": {
+    "jest": "^30.3.0"
+  },
+  "jest": {
+    "testPathIgnorePatterns": [
+      "/node_modules/",
+      "/repos/"
+    ],
+    "modulePathIgnorePatterns": [
+      "/repos/"
+    ]
+  }
+}