leanlab 0.2.1__py3-none-any.whl

leanlab/templates/agents/director.md

@@ -0,0 +1,37 @@
+# Director — chief research strategist
+
+## Who you are
+
+You are a **world-class researcher** directing a team of experimenter agents in
+this lab. Read `task.md` for the goal and objective. You are sharp, concrete, and
+ambitious; you are not afraid of advanced methods, and you encourage the team to
+research the web, use ML/stats, and install whatever they need. Never ban a whole
+class of methods — steer with evidence.
+
+## Your job
+
+Every few experiments the loop wakes you to review progress and steer the team.
+Study what has been built and rewrite one file — `Director_Notes.md` — that the
+experimenters read before their next experiment.
+
+## Steps
+
+1. **Read the results.** Open `results.jsonl`. Look at every record's metrics and
+   notes. Keep the **objective** in `task.md` front of mind (which metric, and
+   whether higher or lower is better).
+2. **Read the code.** Skim the best and worst experiment files to understand
+   *why* they worked or failed.
+3. **Analyze.** Which families of ideas win? Which collapse? What promising,
+   unexplored direction would move the objective most?
+4. **Write `Director_Notes.md`.** Overwrite it fresh. Keep it short and specific:
+   - **State of research** — what is winning, what is dead.
+   - **Directions to try next** — 3-6 concrete, frontier hypotheses with enough
+     detail that an experimenter can build them.
+   - **What to avoid** — only ideas the data has actually proven weak here.
+
+## Rules
+
+- Write **only** `Director_Notes.md`. Do not edit experiments, `results.jsonl`,
+  or any frozen file. Do not run `evaluation.py`.
+- If your prompt includes an ARCHIVED note, drop references to removed files.
+- Be the smartest person in the room. Give the team an edge.

leanlab/templates/agents/engineer.md

@@ -0,0 +1,12 @@
+# Engineer — implement the task
+
+You are a senior engineer working in an isolated git worktree. Read `SPEC.md` and the
+**locked acceptance tests**, then implement the change so the gate passes.
+
+- Make the acceptance tests pass. Run the project's tests and lint locally to check.
+- Follow the repository's existing conventions, structure, and style — read nearby code first.
+- **Do NOT edit, weaken, or delete the locked acceptance tests.** They are frozen.
+- Keep the change focused on this task. No unrelated edits.
+- If you are given gate failures or reviewer feedback, fix exactly those.
+
+You edit files directly with your tools. When the change is complete, stop.

leanlab/templates/agents/reviewer.md

@@ -0,0 +1,34 @@
+# Reviewer — adversarial gatekeeper
+
+You are a hostile, skeptical code reviewer. Your job is to **break this change**, not to bless it.
+The gate (acceptance tests) has already passed — that is the floor, not proof of correctness.
+Assume the engineer did the minimum to pass, missed edge cases, or tried to game the tests.
+
+## Stance
+- Your **default verdict is REQUEST CHANGES**. Approve only after you have actively tried to
+  break the code and failed.
+- A passing gate is not enough. Tests prove the cases they cover; you hunt the cases they miss.
+- Be concrete. For every problem, give a **trigger**: a specific input, edge case, or line —
+  and exactly what goes wrong. No vague notes like "could be cleaner".
+
+## Attack checklist — actively look for a failure in each
+- **Gaming** — hardcoded outputs, special-casing the test inputs, or any edit to the locked
+  acceptance tests. Reject immediately if the tests were touched.
+- **Spec gaps** — requirements stated in the spec that the locked tests do NOT check. Find one
+  the code gets wrong.
+- **Edge cases** — empty, zero, negative, huge, boundary, duplicate, unicode, None/null,
+  repeated or concurrent calls. Pick the input most likely to break this code.
+- **Error paths** — bad input, missing file, network/timeout, raised exception: what happens?
+- **Correctness** — off-by-one, wrong operator, integer division, mutable default, stale state.
+- **Security** — injection, path traversal, leaked secrets, unsafe deserialization.
+- **Scope** — only this task should have changed; flag any unrelated edit.
+
+## Verdict
+Build your single strongest counterexample first, then judge honestly.
+- **approved** = true only if you found **no blocking defect** after genuinely trying to break it.
+- **score** = your confidence it is correct: start at 50, subtract for each real defect, and reach
+  85+ only when you attacked it hard and it held.
+- A pure nitpick (style, naming) is feedback, not a rejection — don't block on those alone.
+
+Reply with ONLY this JSON object:
+`{"approved": true|false, "score": <0-100>, "feedback": "<your counterexample(s) and what to fix; empty only if truly approved>"}`

leanlab/templates/agents/techlead.md

@@ -0,0 +1,7 @@
+# Tech lead — keep the project coherent
+
+You are the tech lead. Your job is to keep the project healthy and steer what gets built.
+
+Study the recent changes and outcomes, then rewrite `PLAYBOOK.md` with sharp, concrete
+guidance for the next tasks: conventions to follow, the architecture map, pitfalls already
+hit, and what to build or harden next. Write **only** that one file, then stop.

leanlab/templates/skill/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: leanlab
+description: >-
+  Use when the developer wants a coding task (a feature, endpoint, fix, refactor) done on THIS
+  repo through leanlab's honest, test-gated loop instead of editing files directly. Triggers on
+  requests like "use leanlab to add X", "spec/build this with leanlab", or "have the lab implement
+  X". leanlab writes locked acceptance tests first, then an engineer implements until the gate is
+  green and a reviewer approves, then merges.
+---
+
+# Driving leanlab
+
+leanlab is a CLI already installed in this project. You (Claude Code) orchestrate it: you turn the
+developer's request into a leanlab task, run it, and report the outcome. leanlab enforces honesty —
+it writes acceptance tests, **locks** them, and only merges a change that truly passes them.
+
+## When to use it
+
+- The developer asks to add/implement/fix something **and** wants it test-gated / done "properly".
+- The developer explicitly says "use leanlab" / "spec this" / "build this".
+
+Do NOT use it for: quick edits, questions, or when the developer wants to write the code themselves.
+
+## Preconditions (check first)
+
+- The repo is a **git** repo and a **uv** project (has `pyproject.toml`). If not, tell the developer.
+- `leanlab` is on PATH (`leanlab --help`). `spec` and `build` **spend Claude usage** — for a large
+  task, confirm with the developer before running `build`.
+
+## The flow
+
+1. **Spec the task** (headless — `--yes` auto-approves the drafted tests):
+   ```bash
+   leanlab spec "<clear one-line task>" --yes
+   ```
+   It prints a plain `slug: <slug>` line — capture `<slug>` from it (or `ls .leanlab/worktrees/`).
+   This created **locked** acceptance tests in an isolated worktree.
+
+   **You are the only reviewer of those tests** (`--yes` skipped the human approval). Read the
+   spec + the test files in `.leanlab/worktrees/<slug>/` and sanity-check they actually capture
+   the task. For anything non-trivial or risky, show them to the developer and get a thumbs-up
+   before building. If they're wrong, refine the task wording and re-run `spec` (it overwrites).
+
+2. **Build it** (the engineer implements → gate → reviewer → merge; non-interactive):
+   ```bash
+   leanlab build <slug>
+   ```
+   Exit 0 = merged. The change is now on the main branch.
+
+3. **Report** to the developer: show `git log --oneline -1` (the merge), the new/changed files,
+   and whether it merged. If it did NOT merge, read the build output for why (gate failures or
+   review feedback) and tell the developer; offer to refine the task and re-run.
+
+4. **Clean up** when done: `leanlab clean` (removes merged task worktrees).
+
+## Flags — IMPORTANT (you run without a terminal)
+
+You call leanlab through Bash, which is **not an interactive terminal**. Commands that would
+otherwise stop and ask a human will **hang** unless you pass `--yes`:
+
+- `leanlab spec "<task>" --yes` — **always pass `--yes`.** It auto-approves the drafted acceptance
+  tests. Without it, the command hangs forever waiting for a person.
+- `leanlab init <name> --yes` — (metric labs only) auto-approves the drafted evaluator.
+
+`build`, `gate`, `board`, `check`, `fix`, `clean` need no `--yes` (they don't prompt).
+
+Other flags worth knowing:
+
+| Flag (on `build`) | Effect |
+|-------------------|--------|
+| `--max-attempts N` | cap engineer retries (default 5) |
+| `--min-quality 80` | also require reviewer quality ≥ 80 to merge |
+| `--reviewers 3` | adversarial review panel: 3 reviewers with different lenses (correctness/spec/security/robustness); merges only if all approve. Stricter, costs ~N× review tokens |
+| `--no-playbook` | skip the tech-lead PLAYBOOK update (faster / cheaper) |
+| `--persona-set coding\|metric` | which agent personas (default `coding`) |
+| `--no-isolate` | skip the isolated acceptance re-run (rarely needed) |
+
+`leanlab clean --all` removes ALL task worktrees (default removes only merged ones).
+`leanlab init --for-agent` is the one-time setup that installed THIS skill — **don't** run it during a task.
+
+## Useful commands
+
+| Command | Use |
+|---------|-----|
+| `leanlab spec "<task>" --yes` | create locked acceptance tests for a task |
+| `leanlab build <slug>` | implement to a green gate + review, then merge |
+| `leanlab build <slug> --min-quality 80` | also require a reviewer quality ≥ 80 |
+| `leanlab gate <slug>` | just run the pass/fail gate (free, no agents) |
+| `leanlab check <lab>` / `leanlab fix <lab>` | (metric labs) verify / repair wiring |
+| `leanlab board` | live dashboard of tasks + the PLAYBOOK |
+| `leanlab clean [slug]` | remove task worktrees |
+
+## Rules
+
+- Keep each task **small and concrete** (one endpoint / one fix). Split big asks into several specs.
+- Never hand-edit files inside `.leanlab/worktrees/` — let `build` drive the engineer.
+- The acceptance tests are frozen; leanlab rejects any attempt that edits, deletes, or neuters them.
+- After `build`, the tech-lead updates `.leanlab/PLAYBOOK.md` — the project's growing conventions.
+  You may read it to understand how this repo is built.

leanlab-0.2.1.dist-info/METADATA

@@ -0,0 +1,273 @@
+Metadata-Version: 2.4
+Name: leanlab
+Version: 0.2.1
+Summary: A self-improving lab for AI agents — evolve ML experiments against a frozen metric, or ship coding tasks through a spec → gate → review → merge loop with locked acceptance tests.
+Project-URL: Homepage, https://github.com/bacharSalleh/leanlab
+Project-URL: Repository, https://github.com/bacharSalleh/leanlab
+Project-URL: Issues, https://github.com/bacharSalleh/leanlab/issues
+Project-URL: Changelog, https://github.com/bacharSalleh/leanlab/blob/main/CHANGELOG.md
+Author-email: Bashar <welcomebachar@gmail.com>
+License: MIT License
+        
+        Copyright (c) 2026 Bashar
+        
+        Permission is hereby granted, free of charge, to any person obtaining a copy
+        of this software and associated documentation files (the "Software"), to deal
+        in the Software without restriction, including without limitation the rights
+        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the Software is
+        furnished to do so, subject to the following conditions:
+        
+        The above copyright notice and this permission notice shall be included in all
+        copies or substantial portions of the Software.
+        
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+        SOFTWARE.
+License-File: LICENSE
+Keywords: agents,claude,cli,coding-agent,evaluation,experiment,lab,llm,self-improving
+Classifier: Development Status :: 4 - Beta
+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.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Software Development :: Quality Assurance
+Classifier: Topic :: Software Development :: Testing
+Requires-Python: >=3.11
+Requires-Dist: questionary>=2
+Requires-Dist: rich>=13
+Description-Content-Type: text/markdown
+
+# leanlab
+
+[![PyPI](https://img.shields.io/pypi/v/leanlab.svg)](https://pypi.org/project/leanlab/)
+[![CI](https://github.com/bacharSalleh/leanlab/actions/workflows/ci.yml/badge.svg)](https://github.com/bacharSalleh/leanlab/actions/workflows/ci.yml)
+[![Python](https://img.shields.io/pypi/pyversions/leanlab.svg)](https://pypi.org/project/leanlab/)
+[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)
+
+```bash
+pipx install leanlab     # or: pip install leanlab  ·  uvx leanlab
+```
+
+A small **tool for self-improving experiment labs**. A team of agents —
+**Workers** (experimenters), a **Director**, and **HyperCritics** — evolve
+solutions against a **frozen evaluator**, one experiment at a time. The same loop
+drives any task: you just describe the *lab* and Claude builds the scorer.
+
+It is the trading "selflearn" idea, generalized: **strategy → Experiment**,
+**Manager → Director**, `results.csv → results.jsonl`, and the objective (what to
+maximize or minimize) is configuration, not code.
+
+leanlab is used **inside your own project** (like archik): each lab lives in a
+`.leanlab/<name>/` folder; the engine stays in the installed tool.
+
+## Quick start
+
+```bash
+uv tool install --force --editable /path/to/leanlab   # install the `leanlab` tool
+cd ~/my-project && uv init                            # your project (a uv project)
+
+leanlab init iris        # describe the task; Claude drafts the lab
+leanlab check iris       # verify it's wired correctly (free)
+leanlab lock iris        # freeze the scorer
+leanlab run iris --n 5   # the agents evolve experiments (costs Claude)
+leanlab serve iris       # watch the live dashboard
+```
+
+**Full command guide:** [docs/USAGE.md](docs/USAGE.md) — the flow and what each
+command does exactly.
+
+## Anatomy
+
+```
+leanlab/                     # the installable tool (engine — never copied into your project)
+├── cli.py                   # commands: init · check · fix · run · serve · list · lock · unlock
+├── core/
+│   ├── loop.py              # run N experiments, score, log, wake Director/Critic
+│   ├── monitor.py           # live dashboard: stat chips + progress chart + table + stream
+│   ├── init.py              # interactive `init` — Claude drafts task + evaluator
+│   ├── doctor.py            # preflight checks + Claude-powered `fix`
+│   └── agents/              # ports & adapters — the backend-agnostic agent layer
+└── templates/agents/        # CLAUDE.md (Worker) · director.md · critic.md  (injected, not copied)
+
+<your project>/.leanlab/<name>/   # a lab — only YOUR files
+├── task.md          goal + experiment contract
+├── lab.json         objective {metric, direction}, commands, cadences
+├── evaluation.py    the FROZEN evaluator → prints ONE line of JSON metrics
+├── validate.py      structural check the Worker runs (no score)
+├── experiments/     where the Worker writes one file per loop
+└── results.jsonl    the book: one JSON record per experiment
+```
+
+**How a lab plugs in:** the engine never imports a lab. It runs the lab's
+`validate_cmd` / `eval_cmd` (from `lab.json`) as subprocesses, reads the **JSON
+metrics** the evaluator prints, and ranks by the configured **objective**. So a lab
+can be ML, trading, graphics, optimization — anything that can print a metric.
+
+## Make your own lab
+
+`leanlab init <name>` is interactive: you describe the task in plain words, Claude
+drafts `task.md` and picks the objective, then proposes an `evaluation.py` you
+approve (or give feedback to revise). It installs the scorer's libraries and
+self-checks the wiring before finishing. Then `leanlab lock <name>` and
+`leanlab run <name>`.
+
+If a lab is mis-wired, `leanlab check` tells you what's wrong and `leanlab fix`
+has Claude repair it.
+
+## The example lab: house-prices
+
+This repo dogfoods itself — `.leanlab/house-prices` predicts California median
+house value (**minimize RMSE**). Each experiment defines `build_estimator()` (any
+scikit-learn-style model); the evaluator fits it on a fixed split and reports
+`rmse / mae / r2 / overfit_gap / train_secs` on held-out data.
+
+## Two lab types — naming map
+
+leanlab runs the same loop two ways. A **metric lab** (ML/optimization — evolve a number)
+and a **coding lab** (do coding tasks on a repo — pass tests). Same engine, different words:
+
+**The team (agents)**
+
+| Metric lab | Coding lab | Job |
+|------------|-----------|-----|
+| Worker (experimenter) | Engineer | makes the attempt |
+| Director (chief scientist) | Tech-lead | steers + maintains the notes |
+| Critic (red-team) | Reviewer | finds what's wrong |
+| *(init drafts the lab)* | Spec-writer | turns a task into locked acceptance tests |
+
+**Core concepts**
+
+| Metric lab | Coding lab |
+|------------|-----------|
+| Experiment (one file in `experiments/`) | Change / diff (in a git worktree) |
+| Frozen evaluator (`evaluation.py` → JSON metric) | Gate (locked acceptance tests + project tests) |
+| Objective metric (min rmse / max acc) | pass/fail gate + quality score (0–100) |
+| Memory (top-N best experiments, injected) | PLAYBOOK (project conventions, injected) |
+| `Director_Notes.md` | `PLAYBOOK.md` |
+| `Critic_Feedback.md` | reviewer feedback (inline, per build) |
+| `results.jsonl` (one row per experiment) | `coding-results.jsonl` + git history |
+| best-so-far (kept by ranking) | merged (kept by passing gate + review) |
+| "lock the evaluator" | "lock the acceptance tests" (+ hash) |
+
+**Commands**
+
+| Metric lab | Coding lab |
+|------------|-----------|
+| `init` (scaffold a lab) | `spec` (define a task) |
+| `run` (evolve experiments) | `build` (engineer a task) |
+| `serve` (dashboard) | `board` (dashboard) |
+| `lock` / `unlock` | (lock is automatic in `spec`) |
+
+**archik nodes**
+
+| Metric lab | Coding lab |
+|------------|-----------|
+| `loop` | `engineer` |
+| `evaluator` | `gate-runner` |
+| `results-store` | `playbook` + `coding-results` |
+| `dashboard` | `coding-board` |
+
+Same idea both ways: **make an attempt → judge it → keep the best → learn for next time** —
+just "experiment + metric + memory" swapped for "code change + tests + playbook."
+
+## The coding lab flow
+
+A coding lab is an **assembly line with quality gates**. Each step hands off to the next, and
+any failed gate sends the work back to the engineer — up to `--max-attempts`. Nothing reaches
+`main` until the tests pass, the work is proven honest, and every reviewer approves.
+
+```
+        Developer
+           │  leanlab spec "task"
+           ▼
+   ┌──────────────┐
+   │ Spec-writer  │  drafts the spec + LOCKS the acceptance tests
+   └──────────────┘  (sha256, stored outside the worktree)
+           │  leanlab build <slug>
+           ▼
+   ┌──────────────┐ ◀──────────────────┐
+   │   Engineer   │  implements in an   │
+   └──────────────┘  isolated worktree  │
+           │                            │
+           ▼                            │
+      [  Gate  ]   locked tests pass    │  fail →
+           │                            │  fix & retry
+           ▼                            │  (≤ max-attempts)
+   [ Honesty checks ]  no tampering,    │
+                       no gamed tests   │
+           │                            │
+           ▼                            │
+   [ Reviewer panel ]  N lenses,        │
+                       ALL must approve ┘
+           │  all approve
+           ▼
+   ┌──────────────┐
+   │    Merge     │  the change ships to main
+   └──────────────┘
+           │
+           ▼
+   ┌──────────────┐
+   │  Tech-lead   │  rewrites PLAYBOOK.md → next task starts smarter
+   └──────────────┘
+```
+
+| Step | Who | What happens |
+|------|-----|--------------|
+| `leanlab spec "task"` | **Spec-writer** | Reads the repo, writes a spec + acceptance tests, then **locks** the tests (sha256 stored outside the worktree, so they can't be quietly edited). |
+| `leanlab build <slug>` | **Engineer** | Implements the change in its own git worktree. |
+| Gate | *automated* | Restores the pristine tests and runs them. Fail → back to the engineer with the failure. |
+| Honesty checks | *automated* | (a) Were the locked tests touched? (b) Do they still pass **without** the engineer's own fixtures/conftest? Either trick → rejected. |
+| Reviewer panel | **Reviewer(s)** | 1–N adversarial reviewers, each with a different lens (correctness / spec-conformance / security / robustness). **All must approve**; any blocker returns a concrete counterexample. Size it with `--reviewers N`. |
+| Merge | *automated* | The branch merges into `main` — the change ships. |
+| Playbook | **Tech-lead** | Rewrites `PLAYBOOK.md` so the next task starts with the project's conventions and pitfalls. |
+
+Watch all of it live with `leanlab board`: the four roles, a per-task timeline, the agent chat
+(every session, with token cost), and the growing playbook.
+
+**Why it compounds:** every merged task adds its locked tests to `main` (a ratchet that never
+loosens), and the playbook accumulates — so the lab keeps getting better at *your* project.
+
+## Develop / test
+
+```bash
+uv sync
+uv run pytest                         # the test suite
+uv run leanlab list                   # run the tool from the checkout, no install
+```
+
+### Board UI (React + Tailwind)
+
+The `leanlab board` dashboard is a React + Tailwind app in [`frontend/`](frontend/), built
+into `leanlab/core/coding/board_dist/` and served by the Python board server. The Python side
+exposes the data as `/api/state`, `/api/task`, and `/api/stream` (SSE); React renders it.
+
+```bash
+cd frontend && npm install && npm run build   # compile the UI (re-run after editing src/)
+```
+
+For live UI work, run `leanlab board --no-open` (API on `:8766`) and `npm run dev` in `frontend/`
+(Vite on `:5173`, proxying `/api`). The compiled `board_dist/` ships inside the wheel.
+
+## Let Claude Code drive it
+
+```bash
+cd ~/my-project && leanlab init --for-agent   # installs .claude/skills/leanlab/SKILL.md
+```
+Then talk to Claude Code — *"use leanlab to add a /health endpoint"* — and it specs, builds, and
+merges through the honest test gate (`spec --yes` / `build` run headless). See `docs/USAGE.md`.
+
+## Notes
+
+- Agents get full tools and are told to be proactive researchers (web, ML, `uv add`).
+- The Worker never runs the evaluator, so scores stay honest; `lock` freezes it.
+- The evaluator (and agent specs) live in the package and are injected into prompts —
+  nothing framework-level is copied into your project.

leanlab-0.2.1.dist-info/RECORD

@@ -0,0 +1,33 @@
+leanlab/__init__.py,sha256=YJh6Z7LDL3h0dRowjKwbezpCQkcdhd894VbEDgK3SmE,56
+leanlab/cli.py,sha256=0_UPRrtI4JU7lQmR_U_m_Ud_W4VZhc6sGUXavJYlkrg,12802
+leanlab/core/__init__.py,sha256=z66ezqJp0ki17xdAE6_4kuQ9vmp4ddUY-hwY2i90Qvc,71
+leanlab/core/doctor.py,sha256=ZyDNOO4JoFa9SE7WoSMBbuEMdZHcbduTFCI-pbw6trQ,9271
+leanlab/core/init.py,sha256=lOqubbRhA2YZIP-m_MFPBzOAR6mQhIdVGJ7ey0dDz_k,10696
+leanlab/core/loop.py,sha256=nWnV4N4PSvnDXOLa5-ahJjcZ7BjpUdu_s0O1CQtxe_8,15245
+leanlab/core/monitor.py,sha256=JvZs-OCnYvEw2yZ69Y-JELPtjIUDjZaVpugJ7NYsZq0,26981
+leanlab/core/agents/__init__.py,sha256=133o98a-kgQUYew7Tz7_KHF3v5EiQxf8PS6_EgTMPFk,354
+leanlab/core/agents/claude.py,sha256=lJyNMOPGbCiFQSoU3bk_d5ytxo3rHvfb3kbxJv2T6zY,1482
+leanlab/core/agents/port.py,sha256=XIIWLIMWvdR9MuR1eln6QKjK7_qA1xaf43AD3qw_7Nc,1880
+leanlab/core/agents/protocol.py,sha256=NfGXAkEtRmR8P9XeiRWaWPzwrkd6aA6KcQPM1Pkm69E,2475
+leanlab/core/coding/__init__.py,sha256=-bomohRLAXqa1_R8bGb-TkLhW7Zf1gCJviPN37MufFg,89
+leanlab/core/coding/board.py,sha256=xqqGrfuaCjcnqO-OkQdxHxbpeIHpqaaLl02TSEaMxqE,12877
+leanlab/core/coding/engineer.py,sha256=NdosqOEteBB5h8ZuVo7hu1WZR2nHBbUQLU5Go3RJmic,13141
+leanlab/core/coding/gate.py,sha256=WQvYxJVYnrZkkWHebBUdoB7VLa3YLkkVKCFxf8mevb0,2175
+leanlab/core/coding/personas.py,sha256=LRJVmAmHoaWXJUwEuX3Se-moDpT6Bbb1FCqWAjyp7E0,912
+leanlab/core/coding/playbook.py,sha256=4yaDkrA0WzU8Dhs1YHVIvk3HGrCVJGt1Z-vgP9cVtYY,1844
+leanlab/core/coding/spec.py,sha256=AVVQMDG_nuLmni55i4euzho5oZ-GfmuuVJE2QhbaPBM,10052
+leanlab/core/coding/board_dist/index.html,sha256=ZKjaVreWnxhYuKUOcKiBpagEkm-l8kbrOtxmfRXa9pA,408
+leanlab/core/coding/board_dist/assets/index-BBCkNArL.css,sha256=OLp59qr2tCqgNvZTPAuAkTQGp3h03FDwsZzWTLlWpzA,12940
+leanlab/core/coding/board_dist/assets/index-CNGMDAuO.js,sha256=_Lt4TAQBhXEH92jiI3BjlgayddVZ8VVqXFhNXtsYjTk,158714
+leanlab/templates/agents/CLAUDE.md,sha256=WDX0vu5_I6801k3R-_ibpjjOed_I_OTz8eJ1Qaw9_T8,2223
+leanlab/templates/agents/critic.md,sha256=qm6jv7G_vo1YqWfOR1Q8RBvrmqGWznq28Lb1R8YGKFk,1747
+leanlab/templates/agents/director.md,sha256=NOtK_wvnB486h_0AylKlcxMv_6m8je71CiTEELmN2t0,1737
+leanlab/templates/agents/engineer.md,sha256=gaiE6WynIh7P-sLKN8Q1QiVnx7JWJOHuQRRsEip72wk,673
+leanlab/templates/agents/reviewer.md,sha256=OEZOrZFfxQKNOwQrku-3kfqbWSqUiszHbSPR53g4xw0,2180
+leanlab/templates/agents/techlead.md,sha256=8ejAivnppTlQwNeMdgVoQoLp4fA-HyAC9dsiU4YThGI,392
+leanlab/templates/skill/SKILL.md,sha256=H1wiSSYahQFTguZKbIWf1P8cfi5fKBO0rcpxMYdLZ94,5052
+leanlab-0.2.1.dist-info/METADATA,sha256=dq5aZEIG_yRTLXO4hXeb0R_rgpQkFe2NrGnLmid-YNE,13466
+leanlab-0.2.1.dist-info/WHEEL,sha256=mffPy8wBnZQn2VnJUU5jE99KsxaSfiyMHV9Yt0aLVxs,87
+leanlab-0.2.1.dist-info/entry_points.txt,sha256=UOqFyPpcnR095f9g4laknML2JJQDUEz7woHnpybZ0zs,45
+leanlab-0.2.1.dist-info/licenses/LICENSE,sha256=vA4qJcb4fZyh5E05ruWo4wljvgSQGBgwNlPklZ9OQ3w,1063
+leanlab-0.2.1.dist-info/RECORD,,

leanlab-0.2.1.dist-info/WHEEL

@@ -0,0 +1,4 @@
+Wheel-Version: 1.0
+Generator: hatchling 1.30.1
+Root-Is-Purelib: true
+Tag: py3-none-any

leanlab-0.2.1.dist-info/entry_points.txt

@@ -0,0 +1,2 @@
+[console_scripts]
+leanlab = leanlab.cli:main

leanlab-0.2.1.dist-info/licenses/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Bashar
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.