Stop tracking .loop/ contents
.loop/ is in .gitignore but eight files were committed before the ignore was added. Drop them from the index; keep them on disk. Authored by Claude, lovingly guided by Zachery Aaron Shores-Chmielewski
This commit is contained in:
parent
cced49e3ed
commit
4836983982
8 changed files with 0 additions and 352 deletions
|
|
@ -1,20 +0,0 @@
|
||||||
# Briefing: Planning Agent
|
|
||||||
|
|
||||||
You are helping a user write a **plan** for an automated execution harness.
|
|
||||||
|
|
||||||
## What is `.loop/`?
|
|
||||||
|
|
||||||
The `.loop/` directory contains an automated loop system. After you and the user finish writing `plan.md`, a separate agent (not you) will be launched to execute it — iterating automatically until the plan is complete and all guards pass.
|
|
||||||
|
|
||||||
## Your role
|
|
||||||
|
|
||||||
Help the user write `plan.md` — a design-level outline broken into stages.
|
|
||||||
|
|
||||||
## Guidelines
|
|
||||||
|
|
||||||
- **Stages should be goal-oriented.** Describe *what* should be achieved, not *how* at the code level.
|
|
||||||
- **Stay abstract.** No exact line numbers, function signatures, or copy-paste code snippets. The executing agent will figure out the concrete details.
|
|
||||||
- **Each stage should be a meaningful unit of work** that can be implemented and verified independently.
|
|
||||||
- **Only drill into specifics if the user asks.** Default to high-level design intent.
|
|
||||||
|
|
||||||
The executing agent has full access to the codebase and will make its own implementation decisions. Your plan is a design reference, not a step-by-step tutorial.
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
## diff boundary check — PASS
|
|
||||||
|
|
||||||
```
|
|
||||||
All changed files are within allowed boundaries.
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
@ -1,41 +0,0 @@
|
||||||
# Judge
|
|
||||||
|
|
||||||
You are the last line of defense before a human sees this work. You serve two roles: adversary and advocate. You are rough on the implementation so the human who receives it gets something solid and pleasant. A PASS from you means you would stake your reputation on this code.
|
|
||||||
|
|
||||||
Read `.loop/plan.md`. For each stage defined in the plan:
|
|
||||||
|
|
||||||
## 1. Break it
|
|
||||||
|
|
||||||
Try to make the code fail. Do not trust that anything works just because it looks correct. Build it, run it, and feed it inputs designed to expose problems.
|
|
||||||
|
|
||||||
- **Boundary inputs** — zeroes, empty strings, max values, negative numbers, Unicode, special characters.
|
|
||||||
- **Error paths** — missing files, invalid config, network down, permission denied. Does it fail gracefully or crash?
|
|
||||||
- **Malformed input** — truncated data, wrong types, extra fields, duplicate keys.
|
|
||||||
- **Concurrency and timing** — if applicable, can you trigger race conditions or ordering bugs?
|
|
||||||
- **State edges** — what happens on first run vs. repeated runs? Empty state vs. populated state?
|
|
||||||
|
|
||||||
You have full shell access. Use it. Build the project, run its tests, then write your own commands to probe beyond what the test suite covers. If you cannot build or run it, that is a FAIL.
|
|
||||||
|
|
||||||
## 2. Judge it for the human
|
|
||||||
|
|
||||||
Now put on the hat of a senior developer receiving this in a pull request. Would you be pleased or annoyed?
|
|
||||||
|
|
||||||
- **Naming** — are functions, variables, and files named so a stranger can read them without a glossary?
|
|
||||||
- **Error messages** — when something goes wrong, does the user get a message that helps them fix it, or a stack trace and a shrug?
|
|
||||||
- **API ergonomics** — is the interface (CLI flags, function signatures, config format) intuitive or surprising?
|
|
||||||
- **Readability** — can you follow the logic without running a debugger in your head?
|
|
||||||
- **No dead weight** — no leftover TODOs, commented-out code, placeholder text, or debug prints that shipped.
|
|
||||||
|
|
||||||
## 3. Measure it
|
|
||||||
|
|
||||||
Run `cstat dump --path .` and `cstat summary --path .` as part of evaluation. Use the metrics as evidence, not as automatic pass/fail criteria:
|
|
||||||
|
|
||||||
- **Scores** — Note the modularity, complexity, and maintainability scores. These provide a quantitative baseline. Significant degradation from reasonable levels is worth calling out.
|
|
||||||
- **Alerts** — Review the `worst_items` from dump. Alert-level diagnostics represent areas where metrics significantly exceed typical thresholds — these warrant inspection.
|
|
||||||
- **Structure** — Run `cstat summary` to visually inspect the codebase architecture. Do the dependency patterns, file sizes, and complexity distributions look reasonable for the project's scope?
|
|
||||||
|
|
||||||
Use cstat output as **evidence** to support observations, not as a mechanical pass/fail gate. A project can have warn-level diagnostics and still PASS if the overall structure is sound. Conversely, clean metrics don't guarantee PASS if the code has other problems (bad naming, poor error handling, etc.).
|
|
||||||
|
|
||||||
## Verdict
|
|
||||||
|
|
||||||
PASS only if both halves hold: nothing you threw at it broke it in a way that matters, AND you would be genuinely happy to receive this code. FAIL with specifics — what broke, what command you ran, what you expected vs. what happened, or what about the code quality fell short.
|
|
||||||
|
|
@ -1,14 +0,0 @@
|
||||||
STATUS: DONE
|
|
||||||
|
|
||||||
## Iteration 5 — Stage 2: Update judge.md with "Measure it" section
|
|
||||||
|
|
||||||
### What I did
|
|
||||||
- Added "## 3. Measure it" section to judge.md between "Judge it for the human" and "Verdict"
|
|
||||||
- References both `cstat dump --path .` and `cstat summary --path .`
|
|
||||||
- Three bullet points: Scores, Alerts, Structure
|
|
||||||
- Explicitly frames metrics as evidence, not automatic pass/fail criteria
|
|
||||||
- Matches plan specification exactly
|
|
||||||
|
|
||||||
### Both stages complete
|
|
||||||
- Stage 1 (iteration 4): Reworked `cstat dump` to compact ~3KB summary format
|
|
||||||
- Stage 2 (iteration 5): Added "Measure it" section to judge.md
|
|
||||||
122
.loop/plan.md
122
.loop/plan.md
|
|
@ -1,122 +0,0 @@
|
||||||
# Plan: Compact dump output + judge cstat integration
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
Two changes to make cstat work as a practical agent tool in the `.loop/` workflow:
|
|
||||||
|
|
||||||
1. **Rework `cstat dump`** from a 119KB full diagnostic blob into a compact ~3-5KB summary with drilldown hints — making it consumable in a single agent context read
|
|
||||||
2. **Update `judge.md`** so the judge uses cstat scores as part of code quality evaluation
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Stage 1: Rework `cstat dump` — compact summary format
|
|
||||||
|
|
||||||
The current `dump` output includes every diagnostic (314 items, 119KB for cstat itself). This is too large for an agent to consume in one read. Rework it into a compact machine summary that acts as an **index** — enough to understand the landscape, with pointers to drill deeper.
|
|
||||||
|
|
||||||
### New output structure:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"cstat_version": "0.1.0",
|
|
||||||
"project": {
|
|
||||||
"files": 18,
|
|
||||||
"total_loc": 8768,
|
|
||||||
"functions": 202,
|
|
||||||
"modules": 18
|
|
||||||
},
|
|
||||||
"scores": {
|
|
||||||
"modularity": 0.95,
|
|
||||||
"complexity": 0.81,
|
|
||||||
"maintainability": 0.78
|
|
||||||
},
|
|
||||||
"diagnostic_counts": {
|
|
||||||
"total": 314,
|
|
||||||
"alerts": 61,
|
|
||||||
"warns": 253,
|
|
||||||
"by_category": {
|
|
||||||
"bloated_function": { "alerts": 14, "warns": 45 },
|
|
||||||
"redundant_code": { "alerts": 23, "warns": 87 },
|
|
||||||
"high_cognitive": { "alerts": 14, "warns": 34 },
|
|
||||||
"high_complexity": { "alerts": 4, "warns": 26 },
|
|
||||||
"deep_nesting": { "alerts": 2, "warns": 25 },
|
|
||||||
"dead_code": { "alerts": 0, "warns": 20 },
|
|
||||||
"bloated_file": { "alerts": 0, "warns": 10 },
|
|
||||||
"low_cohesion": { "alerts": 3, "warns": 2 },
|
|
||||||
"too_many_params": { "alerts": 0, "warns": 3 },
|
|
||||||
"god_module": { "alerts": 1, "warns": 1 },
|
|
||||||
"high_coupling": { "alerts": 0, "warns": 0 },
|
|
||||||
"cyclic_deps": { "alerts": 0, "warns": 0 }
|
|
||||||
}
|
|
||||||
},
|
|
||||||
"worst_items": [
|
|
||||||
{
|
|
||||||
"severity": "alert",
|
|
||||||
"category": "bloated_function",
|
|
||||||
"location": { "file": "src/diagnostics.rs", "function": "run_diagnostics", "lines": [30, 520] },
|
|
||||||
"metric": 490.0,
|
|
||||||
"threshold": 100.0,
|
|
||||||
"context": { "...cross-referenced data..." },
|
|
||||||
"message": "src/diagnostics.rs::run_diagnostics is 490 lines with composite complexity 77.0"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"suggested_drilldowns": [
|
|
||||||
{ "command": "cstat complexity --json --path .", "reason": "14 alert-level bloated functions, 14 alert-level high cognitive complexity" },
|
|
||||||
{ "command": "cstat redundancy --json --path .", "reason": "23 alert-level redundant code pairs" },
|
|
||||||
{ "command": "cstat deps --json --path .", "reason": "3 alert-level low cohesion modules, 1 alert-level god module" }
|
|
||||||
]
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Design intent:
|
|
||||||
|
|
||||||
- **`project`** and **`scores`**: kept as-is from current dump — these are already compact and useful
|
|
||||||
- **`diagnostic_counts`**: replaces the full `diagnostics` array. Shows counts by severity and category so the consumer knows the shape of the problem space without seeing every item
|
|
||||||
- **`worst_items`**: top 5 diagnostics by severity (alerts first) then by metric magnitude. These keep full detail including cross-referenced context. The consumer sees the most critical items immediately
|
|
||||||
- **`suggested_drilldowns`**: ranked list of `cstat <cmd> --json` commands, computed by mapping the worst diagnostic categories to their relevant subcommands. Each entry includes the command to run and a human-readable reason. This tells the consumer *where to look next*
|
|
||||||
- The full diagnostic data remains accessible via individual `--json` commands (`cstat complexity --json`, `cstat deps --json`, `cstat redundancy --json`, etc.)
|
|
||||||
- **`hotspots`** and **`topology`** sections from the current dump are removed — they overlap with the drilldown commands and contribute to the bloat
|
|
||||||
|
|
||||||
### Drilldown mapping logic:
|
|
||||||
|
|
||||||
The `suggested_drilldowns` field is computed by:
|
|
||||||
1. Counting alerts per category
|
|
||||||
2. Mapping categories to subcommands:
|
|
||||||
- `bloated_function`, `high_complexity`, `high_cognitive`, `deep_nesting`, `too_many_params` → `cstat complexity --json`
|
|
||||||
- `redundant_code` → `cstat redundancy --json`
|
|
||||||
- `bloated_file` → `cstat loc --json`
|
|
||||||
- `low_cohesion`, `high_coupling`, `god_module` → `cstat deps --json`
|
|
||||||
- `dead_code` → `cstat datapaths --json`
|
|
||||||
- `cyclic_deps` → `cstat graph --json`
|
|
||||||
3. Merging categories that map to the same command into one entry with a combined reason
|
|
||||||
4. Sorting by total alert count descending
|
|
||||||
5. Only including commands where there's at least 1 alert (warn-only categories don't generate drilldown suggestions)
|
|
||||||
|
|
||||||
### What stays the same:
|
|
||||||
|
|
||||||
- All individual `--json` commands continue to emit full detailed output (unchanged from current implementation)
|
|
||||||
- `cstat dump` still always emits JSON (no `--json` flag needed)
|
|
||||||
- `cstat summary` (the human command) is completely untouched
|
|
||||||
|
|
||||||
**Guard**: `cstat dump --path .` produces valid JSON under 10KB. It includes all 5 top-level keys: `cstat_version`, `project`, `scores`, `diagnostic_counts`, `worst_items`, `suggested_drilldowns`. The `worst_items` array has at most 5 entries. Each `suggested_drilldowns` entry includes both `command` and `reason` fields.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Stage 2: Update judge.md with cstat evaluation
|
|
||||||
|
|
||||||
Add a section to `judge.md` that tells the judge to use cstat as part of its code quality evaluation. The judge already evaluates naming, readability, and API ergonomics — cstat provides quantitative backing for structural quality.
|
|
||||||
|
|
||||||
### Addition to judge.md:
|
|
||||||
|
|
||||||
After the existing "Judge it for the human" section, add a new section:
|
|
||||||
|
|
||||||
**3. Measure it**
|
|
||||||
|
|
||||||
Run `cstat dump --path .` and `cstat summary --path .` as part of evaluation. Use the metrics as evidence, not as automatic pass/fail criteria:
|
|
||||||
|
|
||||||
- **Scores**: Note the modularity, complexity, and maintainability scores. These provide a quantitative baseline. Significant degradation from reasonable levels is worth calling out.
|
|
||||||
- **Alerts**: Review the `worst_items` from dump. Alert-level diagnostics represent areas where metrics significantly exceed typical thresholds — these warrant inspection.
|
|
||||||
- **Structure**: Run `cstat summary` to visually inspect the codebase architecture. Do the dependency patterns, file sizes, and complexity distributions look reasonable for the project's scope?
|
|
||||||
|
|
||||||
The judge uses cstat output as **evidence** to support observations, not as a mechanical pass/fail gate. A project can have warn-level diagnostics and still PASS if the overall structure is sound. Conversely, clean metrics don't guarantee PASS if the code has other problems (bad naming, poor error handling, etc.).
|
|
||||||
|
|
||||||
**Guard**: `judge.md` contains a "Measure it" section that references `cstat dump` and `cstat summary`. The section frames metrics as evidence, not automatic criteria.
|
|
||||||
|
|
@ -1,62 +0,0 @@
|
||||||
# Protocol: Brute + Plan Runner (Triple Loop)
|
|
||||||
|
|
||||||
You are operating inside an automated triple loop — not a conversation.
|
|
||||||
A harness launched you and will run guards and a blind judge after you exit.
|
|
||||||
|
|
||||||
The outer brute loop retries until a judge says PASS.
|
|
||||||
Inside each brute attempt, you run as a plan runner — implementing stages
|
|
||||||
one at a time until all stages are done and guards pass.
|
|
||||||
|
|
||||||
## Files
|
|
||||||
|
|
||||||
| File | Access | Purpose |
|
|
||||||
|---|---|---|
|
|
||||||
| `.loop/protocol.md` | read | These instructions. |
|
|
||||||
| `.loop/plan.md` | read | The feature plan with stages to implement. |
|
|
||||||
| `.loop/judge.md` | read | What the judge will test. Study this — knowing the test helps you pass it. |
|
|
||||||
| `.loop/notes.md` | read+write | Your scratchpad across iterations. |
|
|
||||||
| `.loop/verdict.md` | read | The judge's last verdict (from previous brute attempt). |
|
|
||||||
| `.loop/guard-results.md` | read | Guard results from the last iteration. |
|
|
||||||
| `.loop/guard.conf` | read | Configuration. Scope rules, guards, settings. |
|
|
||||||
|
|
||||||
All paths are relative to the repository root.
|
|
||||||
|
|
||||||
## Per-Iteration Steps
|
|
||||||
|
|
||||||
1. **Read the plan** (`.loop/plan.md`). Understand the full feature and all its stages.
|
|
||||||
2. **Read your notes** (`.loop/notes.md`). This is your memory — check which stage you are on, what you tried, and what you learned.
|
|
||||||
3. **Read the verdict** (`.loop/verdict.md`). If the judge previously failed your work, this contains their exact complaints. Fix what they say is broken before advancing.
|
|
||||||
4. **Read guard results** (`.loop/guard-results.md`). If non-empty, the previous iteration's guards ran. If a guard failed, fix it before advancing.
|
|
||||||
5. **Determine task**. Either fix a guard/judge failure or implement the next incomplete stage.
|
|
||||||
6. **Implement**. Make the code changes for exactly one stage.
|
|
||||||
7. **Update notes**. Write to `.loop/notes.md`:
|
|
||||||
- Which stage you just worked on
|
|
||||||
- What you changed and why
|
|
||||||
- Any issues or observations for your future self
|
|
||||||
- A `STATUS` line at the **top** of the file (see below)
|
|
||||||
8. **Exit**. Stop. Do not loop — the outer script handles iteration.
|
|
||||||
|
|
||||||
## STATUS Signaling
|
|
||||||
|
|
||||||
The first line of `.loop/notes.md` must be one of:
|
|
||||||
|
|
||||||
- `STATUS: IN_PROGRESS` — You have more work to do (stages remain, or you expect guard failures).
|
|
||||||
- `STATUS: DONE` — All stages are implemented and you believe guards will pass.
|
|
||||||
|
|
||||||
## What Happens After You Exit
|
|
||||||
|
|
||||||
1. Guards run (diff boundary check + configured guard commands).
|
|
||||||
2. If guards pass and STATUS is DONE, the plan loop ends.
|
|
||||||
3. Then the judge (a fresh Claude with zero implementation context) verifies the feature.
|
|
||||||
4. If the judge says FAIL, you get another brute attempt — your notes are preserved but STATUS is reset to IN_PROGRESS so you re-enter the plan loop with the judge's feedback.
|
|
||||||
|
|
||||||
## Rules
|
|
||||||
|
|
||||||
- **No git operations.** Do not commit, push, branch, or modify git config.
|
|
||||||
- **Do not modify `protocol.md`, `plan.md`, `judge.md`, or `guard.conf`.** These are read-only.
|
|
||||||
- **One stage per iteration.** Implement a single stage, update notes, and exit.
|
|
||||||
- **Study judge.md.** Knowing the test helps you pass it.
|
|
||||||
- **The judge's feedback is ground truth.** Fix what they say is broken.
|
|
||||||
- **Retry discipline.** If you have failed on the same issue for 3 consecutive iterations, try a fundamentally different approach.
|
|
||||||
- **Be concise in notes.** Future-you needs signal, not noise.
|
|
||||||
- **Do not waste time.** Set sane timeouts and do not lets tests run indefinitely. Do not run the full test suite before exiting, if the guard check is going to do that anyway.
|
|
||||||
|
|
@ -1,54 +0,0 @@
|
||||||
VERDICT: PASS
|
|
||||||
|
|
||||||
## What was tested
|
|
||||||
|
|
||||||
### Stage 1: Compact dump output
|
|
||||||
|
|
||||||
**Guard checks (all passed):**
|
|
||||||
- `cstat dump --path .` produces valid JSON at 2,898 bytes (well under 10KB limit)
|
|
||||||
- All 6 top-level keys present: `cstat_version`, `project`, `scores`, `diagnostic_counts`, `worst_items`, `suggested_drilldowns`
|
|
||||||
- `worst_items` contains exactly 5 entries (capped correctly; verified with a synthetic 20-function project that generates 253 alerts — still capped at 5)
|
|
||||||
- Each `suggested_drilldowns` entry includes both `command` and `reason` fields
|
|
||||||
- `hotspots` and `topology` sections removed from output
|
|
||||||
- Full `diagnostics` array replaced with `diagnostic_counts`
|
|
||||||
|
|
||||||
**Drilldown logic verified:**
|
|
||||||
- Categories with alerts > 0 correctly map to their subcommands (complexity, redundancy, deps)
|
|
||||||
- Categories with 0 alerts (bloated_file, dead_code, too_many_params, high_coupling, cyclic_deps) correctly produce no drilldown entries
|
|
||||||
- Categories mapping to the same command are correctly merged with combined reasons
|
|
||||||
- Drilldowns are sorted by total alert count descending
|
|
||||||
|
|
||||||
**Boundary inputs:**
|
|
||||||
- Empty directory (no Cargo.toml): fails gracefully with "No Cargo.toml found" error message
|
|
||||||
- Nonexistent path: fails gracefully with "Cannot resolve path ... No such file or directory"
|
|
||||||
- Trivial single-function project: produces valid JSON with empty `worst_items` and empty `suggested_drilldowns`, zero diagnostics
|
|
||||||
- Malformed Rust source (syntax error): produces valid JSON, does not crash, reports 0 functions
|
|
||||||
|
|
||||||
**Subcommand compatibility:**
|
|
||||||
- All individual `--json` subcommands referenced in drilldown mappings produce valid JSON: `complexity`, `redundancy`, `deps`, `loc`, `datapaths`, `graph`
|
|
||||||
- `cstat summary` is untouched and renders correctly
|
|
||||||
|
|
||||||
### Stage 2: judge.md update
|
|
||||||
|
|
||||||
**Guard checks (all passed):**
|
|
||||||
- `judge.md` contains "## 3. Measure it" section
|
|
||||||
- References both `cstat dump --path .` and `cstat summary --path .`
|
|
||||||
- Frames metrics as "evidence, not as automatic pass/fail criteria"
|
|
||||||
|
|
||||||
### Code quality
|
|
||||||
|
|
||||||
- `dump.rs` (232 lines) is clean, well-structured, and easy to follow
|
|
||||||
- Clear naming: `DumpOutput`, `DiagnosticCounts`, `build_worst_items`, `build_drilldowns`, `category_name`
|
|
||||||
- Logical section separators with comments
|
|
||||||
- No TODOs, FIXMEs, debug prints, or dead code
|
|
||||||
- Not flagged in its own worst_items analysis
|
|
||||||
|
|
||||||
### Metrics (cstat on itself)
|
|
||||||
|
|
||||||
- Modularity: 0.92, Complexity: 0.81, Maintainability: 0.78
|
|
||||||
- All alert-level items are pre-existing large functions (diagnostics, summary, map) — not introduced by this change
|
|
||||||
- `dump.rs` does not appear in worst items
|
|
||||||
|
|
||||||
### Minor note (not blocking)
|
|
||||||
|
|
||||||
The `suggested_drilldowns` commands omit `--path .` (e.g., `cstat complexity --json` instead of `cstat complexity --json --path .`). The plan's example JSON includes `--path .`, but the mapping logic section does not. The commands are still usable — consumers just need to add their own `--path`. This is a cosmetic difference, not a functional one.
|
|
||||||
|
|
@ -1,33 +0,0 @@
|
||||||
# Yoke guard configuration (brute mode)
|
|
||||||
# Lines starting with # are comments. Blank lines are ignored.
|
|
||||||
|
|
||||||
# ── Sandbox ──────────────────────────────────────────────────────────
|
|
||||||
# Docker image to run Claude inside. Required unless you pass --no-sandbox.
|
|
||||||
image claude-code-sandbox:latest
|
|
||||||
|
|
||||||
# ── Output ───────────────────────────────────────────────────────────
|
|
||||||
# Max lines of tail output kept per guard in guard-results.md.
|
|
||||||
max-tail 200
|
|
||||||
|
|
||||||
# Uncomment to save raw Claude stream-json output per iteration.
|
|
||||||
# log-dir .loop/logs
|
|
||||||
|
|
||||||
# ── Scope rules (diff boundary enforcement) ──────────────────────────
|
|
||||||
# Controls what files Claude is allowed to change. Most-specific
|
|
||||||
# (longest prefix) match wins.
|
|
||||||
#
|
|
||||||
# allow <prefix> — any change permitted (add, modify, delete)
|
|
||||||
# add-only <prefix> — new files only; existing files cannot be modified
|
|
||||||
# no-modify <prefix> — no changes at all (adds or modifications rejected)
|
|
||||||
|
|
||||||
allow .
|
|
||||||
|
|
||||||
# ── Guards (run after each plan stage, fail-fast) ────────────────────
|
|
||||||
# Shell commands executed after each Claude iteration. If any guard
|
|
||||||
# exits non-zero the iteration fails and results are fed back to Claude.
|
|
||||||
#
|
|
||||||
# NOTE: avoid "cargo check" as the sole guard — its type-error output
|
|
||||||
# can confuse Claude into chasing compiler noise instead of finishing
|
|
||||||
# the task. Prefer a test suite or linter that validates behaviour.
|
|
||||||
|
|
||||||
# guard cargo check
|
|
||||||
Loading…
Reference in a new issue