neuron-explorer
Steering-first neuron explorer for Qwen3.5-4B: push every MLP neuron, keep every rollout, browse the results
翻譯準備中
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證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.