neuron-explorer
Qwen3.5‑4B 전용 조향형 뉴런 탐색기, 모든 MLP 뉴런을 밀어 결과를 보관·탐색
AI 코딩 에이전트를 위해 작업 행동을 인간 승인 실행 불변조건으로 전환하고, 편집기 훅·git pre‑commit·CI로 강제합니다
Turn working behavior into human-approved, executable invariants for AI coding agents, enforced by editor hooks, git pre-commit and CI.
개발 도구Python · TypeScriptGitHub @seamspec온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Your AI agent can't quietly renegotiate what your team agreed. Agreements become tested rules, enforced when the agent finishes, at commit and in CI.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다.
README 전문 보기 ↗Your AI agent can't quietly renegotiate what your team agreed.
When you tell your coding agent "totals must never go negative" or "we tried a thread pool; it deadlocked", that agreement usually lives in one chat and is gone by the next session. SeamSpec turns it into a rule with a test:
From then on, a change that breaks it is stopped, whoever makes it. Changing the rule itself takes your approval.
Status: v0.1, the first release. It works with Claude Code, Cursor, VS Code (Copilot) and Antigravity, for projects tested with pytest or vitest.
You: Other services call enqueue(payload, *, job_id=None, max_attempts=5); keep that working.
And a retry must never wait more than 30 seconds.
Agent: Done. I also proposed both as SeamSpec rules, each with a test.
$ seamspec review ← you read each rule and its test, and approve
✔ inv_846cd96d · A retry never waits more than 30 seconds (fails without your change: YES)
… next week, a new session …
You: Our upstream is flaky; make retries more patient.
Agent: The obvious change conflicts with a rule your team locked (inv_846cd96d: retries
wait at most 30 s). I haven't changed it. Do you want to keep it, or replace the rule?
If an agent or a person changes the code anyway:
To change the rule, the agent files a supersede request and you approve it in seamspec review.
We tested SeamSpec against simpler setups on three small projects, with agreements the later requests tempt the agent to break. Plans and pass bars were fixed before each run, and the results include the ties. Model: Claude Sonnet 5.5.
| Question | Result |
|---|---|
| Agreements only said in chat, nobody writes them down: do they hold three sessions later? | Broken: SeamSpec 0, an agent keeping its own notes 8, nothing 22 (15 runs each). SeamSpec captured 39 of 40 agreements as tested rules. (capture-1) |
A teammate's agent, in a fresh clone, makes the tempting changes: what reaches main? | Landed past CI: SeamSpec 0, the agent's notes 6, nothing 12. SeamSpec's teammate's agent broke 2, and CI stopped both. (second-1) |
| Does the agent rewrite the checks instead of the code? | With plain tests and a Stop hook, it rewrote the rule tests 12 times. SeamSpec's locked tests stayed as approved. (full-1) |
Where SeamSpec does not win, so you can judge for yourself:
CLAUDE.md broke 0 too. A careful agent respects a good notes file. SeamSpec's difference is that its rules are tests, captured for you, enforced at commit and in CI, and changed only with your approval.All the plans, results and allowed claims are in the decision records (ADR-20261018-a4c2, ADR-20261019-c71d).
You need:
The full walkthrough, from install to a team setup with CI, is Getting started.
Install the seamspec command:
uv tool install seamspec
To upgrade later, run uv tool upgrade seamspec.
Then, in your project:
seamspec init
init asks before it changes anything outside your project. It:
.seamspec/);CLAUDE.md / AGENTS.md that tells the agent when to propose rules;--hosts cursor,vscode,antigravity, sets up those editors too.Some editors need a one-time click; see docs/editors.md.
Then just work. Say what must stay true, or tell the agent what failed before. When rules are waiting, run:
seamspec review
The guard that matters for a team is CI: it runs every approved rule on each pull request, whoever wrote the change. Three steps:
.seamspec/ with your code, and add the workflow with seamspec init --ci.seamspec / verify check required for main (branch protection).seamspec init after cloning. A clone doesn't carry anyone's local hooks or consent, and init shows what would run and asks first.Use it with your notes, not instead of them. A good CLAUDE.md helps every agent understand the project. SeamSpec is for the few agreements that would really hurt if broken (money, data contracts, public APIs, security behaviour), so that they're tested, approved, and can't change without someone saying yes. Details: Getting started, section 6.
.seamspec/ and committed with your code. Approving one locks it by hash, so an agent can't quietly edit, skip or empty it.seamspec review shows each test in full, and checks that it fails without the change./seamspec:explain has a separate, read-only reviewer agent explain each item in plain words before you decide.seamspec verify --all --ci).BRAINDUMP.md; the agent sorts it into proposed rules, decisions, dead ends or ideas. Rules whose code doesn't exist yet are kept as planned and shown to the agent until they can be tested.seamspec review | Approve or reject what's waiting: rules, decisions, supersede requests, dead ends |
seamspec status | Rules in force, what's waiting, and how often SeamSpec caught something |
seamspec verify | Run every locked rule now |
seamspec spec | The spec your code has earned: every approved rule, generated from the ledger |
seamspec drain | List the BRAINDUMP notes not sorted yet |
seamspec doctor | Check the setup |
In the agent:
/seamspec:lock to protect a behaviour;/seamspec:dead-end to record what failed;/seamspec:supersede to replace a rule;/seamspec:explain, /seamspec:drain, /seamspec:status.In Cursor, VS Code and Antigravity they are /seamspec-lock and so on. You can also just say it in plain words ("protect this", "that didn't work").
Issues and pull requests are welcome: see CONTRIBUTING.md. To report a security problem privately, see SECURITY.md.