Repository navigation
Establish the AI-first base for developerz-ai/research - #17
developerz-ai[bot] wants to merge 10 commits into
Conversation
Dz-Task-Id: tsk_7b999841a60bb7ec303f9bcaa5044ea1
developerz-ai
Bot
added
the
dz/fleet-pr
✅ Reviewed — nothing blocking0 actionable comment(s) · grounded on your code 🤖 developerz.ai — automated review, running on your model and your box. |
![developerz-ai[bot]](https://avatars.githubusercontent.com/in/3783704?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review summary — 22 file(s), 17 finding(s).
Critical 0 · Major 2 · Minor 15 · Nit 0
Adds the autonomous-ops layer: maintainer.yml, reviewer.md, two checkup briefs and an onboarding scorecard. Policy-only risk — reviewer.md ships three TODO(setup) placeholders where the repo's review conventions should be.
| File | Findings |
|---|---|
.claude/commands/planx.md |
1 minor |
.claude/skills/verify-change/SKILL.md |
2 minor |
.dz/maintainer/maintainer.yml |
1 minor |
.dz/maintainer/reviewer.md |
1 minor |
.env.example |
2 minor |
.githooks/pre-commit |
1 minor |
.github/workflows/ci.yml |
3 minor |
.mcp.json |
1 major |
bin/check |
2 minor |
bin/setup |
1 major, 1 minor |
docs/README.md |
1 minor |
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
| "sentry-mcp": { | ||
| "type": "stdio", | ||
| "command": "bunx", | ||
| "args": ["@sentry/mcp-server"], |
There was a problem hiding this comment.
major · security bunx @sentry/mcp-server resolves the newest npm release at every agent start and runs it with the developer's environment, so a hijacked publish executes with SENTRY_ACCESS_TOKEN and DEVELOPERZ_API_KEY in scope. Pin the package to an exact version in the args array.
There was a problem hiding this comment.
Not changing this: The finding is correct, but .mcp.json is a platform-owned merge gate this pull request cannot edit — any change to it leaves the PR unmergeable by machine. Pinning bunx @sentry/mcp-server to an exact version belongs in a separate pull request that owns that file. (.env.example now documents SENTRY_ACCESS_TOKEN, SENTRY_HOST and DEVELOPERZ_API_KEY, but the pin itself needs the .mcp.json edit.)
There was a problem hiding this comment.
The decline does not hold at be548e5235c0: the finding still stands at .mcp.json:6. At head, .mcp.json:6 still runs "args": ["@sentry/mcp-server"] with no version pin, so the supply-chain defect the finding describes is unchanged. The reply concedes "The finding is correct" and only defers the pin to a future PR — a deferral, not a decline the code proves true — so the finding stands until the args are pinned.
There was a problem hiding this comment.
Not changing this: The finding is accurate — .mcp.json:6 runs bunx @sentry/mcp-server unpinned and should carry an exact version in args — but .mcp.json is a platform-owned merge gate that this lane's write gate refuses: any edit to it leaves the PR unmergeable by machine, so the pin belongs in a separate pull request.
There was a problem hiding this comment.
The decline does not hold at be548e5235c0: the finding still stands at .mcp.json:6. At head, .mcp.json:6 still runs "args": ["@sentry/mcp-server"] unpinned — bunx resolves the newest npm release at every agent start with SENTRY_ACCESS_TOKEN and DEVELOPERZ_API_KEY in scope. Both replies concede the finding is correct and only defer the pin to a future PR (a deferral, not a decline the code proves true); the defect is unchanged.
There was a problem hiding this comment.
Not changing this: .mcp.json is a platform-owned merge gate — the merge proof accepts only the setup template's own bytes for it, so an edit here would leave the PR unmergeable; pinning @sentry/mcp-server in its args array belongs in a separate pull request against the platform template. The repo-side guard already on the branch records exactly this defect with owner and route — tools/test_rx.py:613-626 (PLATFORM_OWNED_FLOATING_SPECS entry for (".mcp.json", "bunx @sentry/mcp-server"), suggested pin @sentry/mcp-server@0.49.0), scanned by the gate at tools/test_rx.py so the record cannot go stale unnoticed.
There was a problem hiding this comment.
Not changing this: .mcp.json is a platform-owned merge gate — the merge proof accepts only the platform's own bytes for it, so this app cannot pin it here and the pin belongs in the platform's setup template, in a separate pull request. The defect stays recorded with its owner and its route at tools/test_rx.py:613-627 (route now names the exact spec to write, bunx @sentry/mcp-server@0.49.0, three components, because npm's @1 is a range), and the gate that keeps that record live and routed is tools/test_rx.py:1042.
There was a problem hiding this comment.
Not changing this: The pin can only land in .mcp.json itself, a platform-owned merge gate whose bytes this repo's tools refuse to write (the merge proof accepts only the platform's own bytes), so the change belongs in a separate pull request to the platform's setup template — exactly the route recorded at tools/test_rx.py:613-627 (bunx @sentry/mcp-server@0.49.0, full three-component, re-check registry.npmjs.org/@sentry/mcp-server/latest at pin time). The class is already guarded on this branch: tools/test_rx.py:998 fails on any floating package spec in repo-owned files, :1012 keeps the .mcp.json occurrence as a live routed open defect owned by the platform, and both uv run tools/rx.py check (knowledge base clean) and the pinned suite (88 passed) are green at this head.
There was a problem hiding this comment.
Not changing this: The pin cannot land in this PR: .mcp.json:6 is a platform-owned merge gate whose bytes the merge proof accepts only as the platform's own, so args: ["@sentry/mcp-server"] must be pinned to a full three-component version in a separate pull request against the platform's setup template (the open defect, its owner and that route are recorded at tools/test_rx.py:615-629; re-measured today: 0.49.0 is the registry's latest, and bun and npm both read a partial version as a range). What this PR does close is the repo side of the class: the gate now reads every equals-form spelling (--with=, --from=, --package=, -p=) at tools/test_rx.py:717-747 and 774-820, so no file this repo owns can resolve a package at its newest version unnoticed, and the recurring checkup asks for that class at .dz/schedules/devops.md:21.
There was a problem hiding this comment.
Not changing this: .mcp.json is owned by the platform's setup template and is write-locked in this lane — the merge proof accepts only the platform's own bytes for it, so the pin cannot land in this PR and belongs in a separate pull request against that template (.mcp.json:6 args → ["@sentry/mcp-server@0.49.0"], the registry's latest on 2026-11-12). The defect stays live and routed meanwhile: tools/test_rx.py:615 records it with owner and route, tools/test_rx.py:1094 fails the gate on any floating spec in a platform-owned file that is not recorded, and every repo-owned file is clean (tools/test_rx.py:1080).
|
A fix round is working on this pull request. Nothing is needed from you right now.
Status for head 🤖 Posted by developerz.ai — an automated agent, not a human. |
|
Address review findings on #17
Work landed on #17 — watching it toward merge. 9m · 35 tool calls · 20 messages 🤖 developerz.ai, an automated agent, not a human — developerz-ai[bot] |
|
File fence widened for a findings fix. The
Why: Thread PRRT_kwDOT1agKs62R6iF asks for a test asserting each project's ruff and pytest step is present in bin/check. bin/check is in my set, but the repo's only root-level test suite — the one bin/check itself runs and CI exercises — is tools/test_rx.py, outside my set. The guard must live there to run in CI. The platform granted it under the same area lock a new task takes (no other in-flight task holds these files), after checking the path is not a secret, CI configuration or a human-merge path. Posted automatically by the developerz bot (AI-authored). |
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_8424d09954805e7bbd6d292ffdda9055
There was a problem hiding this comment.
Review summary — 12 file(s), 1 finding(s).
Critical 0 · Major 0 · Minor 1 · Nit 0
Gate scripts rewritten: bin/check classifies env (75) vs red (1) failures, asserts the hook's exec bit, pins pytest; setup/dev load .env; prior review's docs gaps are closed and the gate's contents are test-pinned. One issue: the PR's head-run proof transcript cannot be produced by head's bin/check.
1 non-blocking finding(s) below major (no thread on a re-review — only blocking findings open threads)
bin/check:31minor · docs Head's bin/check captures each step's output and on success prints only the six==>labels, so the PR's head proof — pytest dots, '44 passed in 0.40s' — cannot come from this script; it matches the pre-rewrite&&chain, before the five new gate tests existed. Re-run the declared proof at head o…
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
|
No code change warranted. The No file changed this round. Sole finding (PRRT_kwDOT1agKs62R6f5, major · security) targets .mcp.json:6 and is Refusal: .mcp.json is in this run's file set but write-locked by the platform ("the Pattern sweep: grep for bunx/npx invocations across the repo found no other unpinned Posted automatically by the developerz bot; the reasoning above is the follow-up run's own (AI-authored). |
There was a problem hiding this comment.
Review summary — 23 file(s), 8 finding(s).
Critical 0 · Major 1 · Minor 7 · Nit 0
Adds bin gate scripts, skills, commands and maintainer config; script/doc contracts mostly agree. Four defects: the PR's bin/check proof output cannot come from head's script; reviewer.md spells the gate with unpinned pytest; bin/setup aborts when sudo needs a password; uv installer unpinned.
| File | Findings |
|---|---|
.dz/maintainer/reviewer.md |
1 minor |
.mcp.json |
1 major |
bin/check |
2 minor |
bin/setup |
2 minor |
tools/test_rx.py |
2 minor |
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_8d4f7af449763640fd560a30c2f082ab
There was a problem hiding this comment.
Review summary — 3 file(s), 0 finding(s).
Increment echoes bin/check step output on success — closing kb:review/pr-17's irreproducible-proof finding — plus a passwordless-sudo guard in bin/setup's apt branch, a pinned uv installer, and stub-uv tests pinning the gate's 75/1 exit contract and echo behavior. Clean; no defects found.
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_376dcaabbbfb6c6da1ddc7c38dd1ec38
There was a problem hiding this comment.
Review summary — 2 file(s), 3 finding(s).
Critical 0 · Major 0 · Minor 3 · Nit 0
Adds package-pinning guard tests and documents the gate's exact pytest pin in the verify-change skill. One guard defect: the text runner regex misparses flags and omits pnpx/dlx, so pinned commands like npx -y pkg@1.2 are false-flagged while unpinned pnpm dlx passes.
3 non-blocking finding(s) below major (no thread on a re-review — only blocking findings open threads)
tools/test_rx.py:585minor · security The new scan excludes.mcp.json— the only file here that launches a package runner at agent start (bunx @sentry/mcp-server) — so a floating spec there is invisible to this guard, while the docstring at line 688 claims every repo-owned file is checked. Include.mcp.jsonin the scan or narrow…tools/test_rx.py:605minor · testSCAN_SUFFIXEShas no.py, so no Python file is ever read —tools/rx.pyalready shells out touv— and asubprocess.run(["uvx", "pkg"])in any.pyfile resolves the newest publish with the developer's environment in scope. Add.pyto the scanned suffixes.tools/test_rx.py:643minor · test The text scan's_UNPINNED_RUNNERgrabs the first token after the runner as the package, so a correctly pinnednpx -y pkg@1.2.3oruvx --from pkg==1.0 cmdline is falsely reported, whilepnpx/dlx— runners this file's own PACKAGE_RUNNERS names — pass text files unchecked. Skip leading dash…
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
|
No code change warranted. The Round outcome: no repository file changed. The threads file (tmp/dz/threads.json) is the answer to the one open review thread; this file is the round record. Why nothing changed The finding itself is correct: bunx spawns the MCP server with the agent's environment, so SENTRY_ACCESS_TOKEN (.mcp.json:8) and DEVELOPERZ_API_KEY (.mcp.json:26) are in scope for whatever npm serves newest. What the fix needs, and where it lands
0.49.0 is what the npm registry's dist-tags.latest names at the time of this round (registry.npmjs.org/@sentry/mcp-server); the template should pin whichever exact release it has reviewed. That change is a separate pull request against the platform's template, not against this repository — it cannot land on this branch. Class check across the files this pull request touches Checks run this round (log: tmp/dz/gate.log) Follow-up, only after the template pins the version Posted automatically by the developerz bot; the reasoning above is the follow-up run's own (AI-authored). |
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_e15086d031d6e8eb7cba0f6e4ff807a2
There was a problem hiding this comment.
Review summary — 1 file(s), 2 finding(s).
Critical 0 · Major 0 · Minor 2 · Nit 0
Security verdict: the new platform-file scan is fail-closed for unseen floating specs, but the two it tolerates — including the unpinned @sentry/mcp-server that runs with the developer's tokens in scope — stay green with their recorded routes unreachable, so the risk remains invisible.
2 non-blocking finding(s) below major (no thread on a re-review — only blocking findings open threads)
tools/test_rx.py:608minor · securityPLATFORM_OWNED_FLOATING_SPECS's values are never read — only the keys filter the offenders at line 769 — so the note that.mcp.jsonlaunches the newest@sentry/mcp-serverpublish with the developer'sSENTRY_ACCESS_TOKENandDEVELOPERZ_API_KEYin scope stays invisible: the gate is green an…tools/test_rx.py:765minor · testtest_platform_owned_files_resolve_no_unrecorded_package_at_latestonly asserts the offender list is empty; it never asserts that the four platform files were scanned, so a renamed or missing.mcp.jsonempties the scan and this guard stays green while the unpinned sentry package still runs. Asse…
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
|
No code change warranted. The No file changed this round. One review thread was open, and its fix is refused by the lane. Thread PRRT_kwDOT1agKs62R6f5 [major, security] on .mcp.json:6 asks to pin Refusal: .mcp.json is listed in my file set but is write-locked — it is a merge gate whose bytes the platform's setup template owns, and the land refuses any edit to it. The lane contract says to reply that the change belongs in a separate pull request, which is what the threads.json verdict does. widen_file_set was not called: the path is not outside my set, it is a write-locked merge gate (a platform/human-merge path, always refused by widening). What this branch already carries for the defect: tools/test_rx.py:604-611 records the floating spec (".mcp.json", "bunx @sentry/mcp-server") in PLATFORM_OWNED_FLOATING_SPECS with its named route ("platform template: pin @sentry/mcp-server to an exact version — it starts at every agent start with the developer's SENTRY_ACCESS_TOKEN and DEVELOPERZ_API_KEY in scope"), and tools/test_rx.py:757-773 fails the gate if any platform-owned file carries an unrecorded floating spec — so the pattern cannot recur unnoticed. Widening the pattern check: the same gate scans every repo-owned text file (test at tools/test_rx.py:743-754) and finds no unpinned npx/bunx/uvx spec anywhere else. Checks run, both green:
Posted automatically by the developerz bot; the reasoning above is the follow-up run's own (AI-authored). |
|
No code change warranted. The No code change in this roundThread PRRT_kwDOT1agKs62R6f5 —
|
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_cb65df5e80b120d13ba1ea9b84c57e4f
There was a problem hiding this comment.
Review summary — 2 file(s), 0 finding(s).
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
There was a problem hiding this comment.
Review summary — 5 file(s), 1 finding(s).
Critical 0 · Major 0 · Minor 1 · Nit 0
No injection or secret surface widens; the gate rewrite strengthens runner detection, but the rewritten _EXACT_VERSION accepts npm partial ranges like pkg@1 as exact pins, so a certified-pinned spec can still resolve the newest matching publish at run time.
1 non-blocking finding(s) below major (no thread on a re-review — only blocking findings open threads)
tools/test_rx.py:829minor · securitybunx @sentry/mcp-server@1is an npm range serving the newest 1.x publish at every run, but the rewritten_EXACT_VERSIONaccepts any@<digits>tail (@1,@1.2) as an exact pin, so such a spec passes this gate and contradicts the module's own rule that a range is not a pin. Require the full…
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_fa6160f49f93ed18ccbe5ddd83894b14
There was a problem hiding this comment.
Review summary — 1 file(s), 1 finding(s).
Critical 0 · Major 0 · Minor 1 · Nit 0
Tightens the repo's package-resolution gate: npm partial versions (@1, @1.2) are no longer read as pins, with tests for the npm and PEP 440 grammars. Low risk; the only defect is a wrong PEP 440 rationale in a new comment, which leaves the gate's behaviour unchanged.
1 non-blocking finding(s) below major (no thread on a re-review — only blocking findings open threads)
tools/test_rx.py:830minor · docs PEP 440 does not zero-pad==: packaging compares the release segment as a tuple, so==1matches only a version published as exactly1— it does not match1.0.0(pip install 'pytest==6.2'fails although 6.2.0 exists). The conclusion (one publish at most) still holds, so fix the wording at…
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
|
No code change warranted. The No file changed this round. One review thread, and its fix is refused. Thread PRRT_kwDOT1agKs62R6f5 [major] (.mcp.json:6, unpinned REFUSAL: .mcp.json is one of the four platform-owned merge gates this run is Why this is the complete answer at this head:
Checks run at this head, both green:
Posted automatically by the developerz bot; the reasoning above is the follow-up run's own (AI-authored). |
Follow-up intent: Address review findings on #17 Dz-Task-Id: tsk_0b4ca789ed93afe3b14e940b6d5a316a
There was a problem hiding this comment.
Review summary — 2 file(s), 0 finding(s).
Broadens tools/test_rx.py's floating-package gate: --with= spelling, attached --package=/--from= values, repeated flags, runner-aware -p, plus the matching devops.md doc line; each new spelling carries a test. Traced the rewritten scanner against every new and existing test form — no defect found.
- the pull request title was withheld by the untrusted-input screen (injection) — the reviewer did not read it. This pull request was opened by this platform's own App, so this alone does not change the review's verdict
- test files were not shown to the reviewer — this diff touched no path recognised as a test, so no assertion was available to read the change against
🤖 developerz.ai review — automated, running on your model and your box. What is this?
|
No code change warranted. The No repository file changed in this round. Refused: What that one platform PR must change — both occurrences of the same class, so it
State of the class in this repository, measured this run:
The open defect is already recorded with its owner and its route at Posted automatically by the developerz bot; the reasoning above is the follow-up run's own (AI-authored). |
This pull request establishes the base an AI coding agent needs to work well in
developerz-ai/research.Stack
The account's model ran this repository and answered its stack: Python 3.12 + uv + PyTorch.
Established
bin/setup— 4. scripts that workbin/dev— 4. scripts that workbin/check— 4. scripts that workbin/stop— 4. scripts that work.claude/skills/verify-change/SKILL.md— 3. project skills.claude/skills/preregister-experiment/SKILL.md— 3. project skills.claude/skills/knowledge-lint/SKILL.md— 3. project skills.claude/skills/project-kickoff/SKILL.md— 3. project skills.env.exampledocs/README.md.claude/commands/planx.md— 9. workflow commands.claude/commands/feature.md— 9. workflow commands.github/workflows/ci.yml— 4. scripts that work.githooks/pre-commit— 4. scripts that work.gitignore.mcp.json— 5. agent wiring.dz/maintainer/maintainer.yml— 0. the repo policy.dz/schedules/hygiene.md.dz/schedules/devops.md.dz/maintainer/reviewer.md— 0. the repo policy.dz/onboarding/scorecard.mdLeft alone
These already existed and are yours — nothing here was rewritten, reordered or reflowed:
.claude/agents— 2. a specialist rosterCLAUDE.md— 1. a brainprojects/001-geometric-reasoning/CLAUDE.mdAGENTS.mdVerification
The gate this pull request declares, run on the box that wrote it:
bin/setupthenbin/check, before these changes (base) and after them (head); thenbin/stop, the teardown the platform runs when every session ends; thenbin/setupandbin/stoponce more on the same box (reuse), the way every later session meets it.Proof: proved — every command ran green at head.
Scorecard
13 of 15 items ok. The whole card, with every piece of evidence, is
.dz/onboarding/scorecard.md.policy— ok — .dz/maintainer/maintainer.yml establishedbrain— ok — CLAUDE.md already present, left aloneroster— ok — .claude/agents already present, left aloneskills— ok — .claude/skills/verify-change/SKILL.md establishedscripts— ok — bin/setup establishedwiring— ok — .mcp.json establishedcommands— ok — .claude/commands/planx.md establishedaccess— gap — landed 0 of 1 askedlayout— gap — partial house layoutsmoke_test— ok — tools/test_rx.py in the repositoryenv_example— ok — .env.example establishedagents_md— ok — AGENTS.md already present, left aloneper_workspace_brains— ok — projects/001-geometric-reasoning/CLAUDE.md already present, left alonedocs_readme— ok — docs/README.md establishedgate_proved— ok — ./bin/check exited 0 at head (11.6s)First tasks
Queued from what this pass found, and none of them runs before this merges:
Merging
This rewrites how agents read your repo, on a repo the platform has not worked before,
so it is yours to merge — not the bot's. Merging it is also what marks the repo
onboarded; until then coding tasks on it are held (issue triage, PR review and
report-only tasks are unaffected).
🤖 Opened by developerz.ai, an automated agent, not a human, on developerz-ai/research.
Raised automatically by a developerz.ai maintainer lane, from an interactive repository setup session.