keelyard 1.0.0__py3-none-any.whl

keelyard/__init__.py

@@ -0,0 +1,3 @@
+"""keelyard: a local trust-and-thrift layer for AI coding agents."""
+
+__version__ = "1.0.0"

keelyard/__main__.py

@@ -0,0 +1,3 @@
+from .cli import main
+
+raise SystemExit(main())

keelyard/adapters/__init__.py

@@ -0,0 +1 @@
+"""Per-agent installers. Each writes project-local config only; nothing global unless asked."""

keelyard/adapters/guides/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: keelyard
+description: Prove work before finishing, undo bad edits, keep context small. Use when changing code in this repo, when a test or edit went wrong and you need to go back, or before telling the user a task is done.
+---
+
+# keelyard
+
+keelyard runs as an MCP server (`keelyard`) plus hooks. Every edit is snapshotted; the Stop
+hook blocks "done" until there is evidence.
+
+## The loop
+
+1. `proof_requirements(items=[...])`: one checkable item per user ask.
+2. `project_map`, `find_symbol(name)`, `outline(path)`, then `read_file(path)`.
+3. Edit. Use `run_compact(command)` for tests and builds.
+4. `proof_run_tests(phase="after")`.
+5. `proof_check(requirement_id, evidence)` for every item. Evidence is a command and its result,
+   or a `path:line`.
+6. `proof_status()` must return `{"proven": true}`.
+
+## When something goes wrong
+
+- `rewind_list()` shows each step with the files it touched.
+- `rewind_diff(step)` shows what a step changed.
+- `rewind_to(step)` restores files. It returns `safety_step`; `rewind_to(safety_step)` undoes it.
+
+## Saving context
+
+- Repeat `read_file` calls on an unchanged file return a one-line notice.
+- `run_compact` keeps failures and `file:line`, drops passing noise; `recall(output_id)` returns the rest.
+- `memory_search(query)` finds how something was solved in an earlier session.
+- `swarm_plan(goal)` splits wide work into per-file tasks with focused context; `swarm(tasks)` runs them on a cheap
+  model and checks every answer (citations exist, patches pass the tests in a copy). With no helper model it
+  returns `subagent_tasks`: send each `subagent_prompt` to your own subagents (Task tool), then `swarm_verify`.
+- keelyard adds short notes to your context (a brief, past-session snippets, hints before destructive commands).
+  They are advisory and rate-limited; act on them when they apply.
+
+## Without MCP
+
+Every action is also a CLI command with `--json`, e.g. `keelyard proof status --json`.
+Exit codes: 0 ok, 1 error, 2 usage error, 3 check not passed.

keelyard/adapters/guides/agents_block.md

@@ -0,0 +1,8 @@
+## keelyard
+
+This project uses keelyard (proof, rewind, smaller context). Rules:
+- Before saying done: proof_requirements, proof_run_tests(phase="after"), proof_check each item. The Stop hook checks.
+- Find code with find_symbol and read_file line ranges; repeat reads of unchanged files are skipped.
+- Noisy commands: run_compact; recall(id) for the full output.
+- Mistake? rewind_list, rewind_to. Every edit is a step.
+- Workflows on demand: workflow("plan" | "debug" | "review").

keelyard/adapters/guides/agents_block_lean.md

@@ -0,0 +1,4 @@
+## keelyard
+
+Every edit is snapshotted (undo: `keelyard rewind list`, `keelyard rewind to N`). Your shell test runs are the proof:
+run the project's tests after your last edit before you finish.

keelyard/adapters/guides/cmd_prove.md

@@ -0,0 +1,9 @@
+---
+description: Prove the current task is done (tests + evidence per requirement)
+argument-hint: [extra requirement]
+---
+Finish the current task with evidence.
+1. If `proof_status` shows no requirements, call `proof_requirements` with the user's asks (plus: $ARGUMENTS).
+2. Call `proof_run_tests` with phase "after". If it fails, fix the cause first.
+3. Call `proof_check` for each open requirement with concrete evidence (command + result, or path:line).
+4. Call `proof_status` and report the result. Do not claim done unless it says proven.

keelyard/adapters/guides/cmd_status.md

@@ -0,0 +1,5 @@
+---
+description: Show keelyard status (snapshots, proof checklist, what is missing)
+---
+Call the keelyard `status` and `proof_status` MCP tools and summarise in three short lines:
+how many snapshots exist, which requirements are proven, and what is still missing.

keelyard/adapters/guides/cmd_undo.md

@@ -0,0 +1,7 @@
+---
+description: Undo recent edits with keelyard rewind
+argument-hint: [step]
+---
+Call `rewind_list`. If a step was given ($ARGUMENTS), call `rewind_diff` on it, then `rewind_to` it.
+Otherwise show the last 10 steps with their files and ask which one to go back to.
+After rewinding, tell the user the `safety_step` they can use to undo the rewind.

keelyard/adapters/guides/terse.md

@@ -0,0 +1 @@
+Be terse: no preamble or recap. Keep code exact.

keelyard/adapters/guides/workflows/debug.md

@@ -0,0 +1,9 @@
+Debug loop. Use when something fails and the cause is not obvious.
+
+1. Reproduce: get one command that shows the failure (run_compact). No reproduction, no fix.
+2. Read the actual error and the stack's top frame in your code. Search memory_search for the error text.
+3. Form one hypothesis that explains all of the evidence. Write it down in one sentence.
+4. Test the hypothesis cheaply: a print, an assertion, or a smaller input. Change one thing at a time.
+5. Wrong hypothesis twice? rewind_to before your experiments, re-read the evidence, widen the search.
+6. Fix the cause, not the symptom. Add a test that failed before the fix and passes after.
+7. Run the full suite once at the end (proof_run_tests phase="after").

keelyard/adapters/guides/workflows/plan.md

@@ -0,0 +1,11 @@
+Plan, implement, verify. Use for any change that touches more than one function.
+
+1. Restate the goal in one line. Write each thing the user asked for as a checkable item: proof_requirements.
+   If something is ambiguous and expensive to get wrong, ask one question now, not later.
+2. Locate before reading: find_symbol, then read_file with a line range. Do not read whole directories.
+3. Plan the smallest change that satisfies every item. List the files you will touch. Name the test that will
+   prove each item; if none exists, write it first and watch it fail (proof_run_tests phase="before").
+4. Implement in small steps. After each step run the narrowest test (run_compact). If a step goes wrong,
+   rewind_to the last good step instead of patching on top of the mess.
+5. Verify: proof_run_tests phase="after", then proof_check each item with the command or path:line that
+   proves it. Report what changed, what was proven, and anything you did not do.

keelyard/adapters/guides/workflows/review.md

@@ -0,0 +1,9 @@
+Review. Use before saying done, or when asked to review a change.
+
+Check the diff (rewind_list, then git diff or the step diffs) against each item, in this order:
+1. Correct: does it do what each requirement says? Edge cases: empty input, None, unicode, large input.
+2. Safe: secrets, injection, unchecked input, destructive operations, error paths that swallow failures.
+3. Tested: is every behaviour change covered by a test that would fail without it?
+4. Small: remove dead code, debug prints, unrelated edits, and new dependencies you did not need.
+5. Clear: names say what things are; comments say why, not what.
+Report findings as path:line with a one-line reason, most serious first. Say "no findings" if there are none.