feat: harness gates for autonomous end-to-end delivery#80
Conversation
npm run check aggregates lint + format:check + typecheck + test + build into one definition of done; CI now runs the same command so local and CI feedback cannot drift. Pin Node via .nvmrc and document environment bootstrap (npm ci first) in AGENTS.md for agents that hit 'command not found' on a fresh clone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New capability-scope-docs test extracts the tool list and declared tool count from docs/capability-scope.md and diffs them against the live tools/list registry, turning the 'update docs with the tool surface' convention into an executable invariant. Contract test assertions now carry failure messages that state what to update when the change is intentional and what was broken when it is not. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Recipes for the three dominant change types (add a tool, modify a tool's surface, fix a bug) with exact file-by-file order, the breaking-change rubric, and pointers to the machine checks that verify each step. Linked from docs/README.md and AGENTS.md so agents read the recipe before executing the task. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New workflow runs the real-api smoke suite (read paths only) via workflow_dispatch, a weekly schedule, or a maintainer-applied real-api PR label, using a dedicated test-account token from repo secrets. Smoke suite grows from 3 to 6 cases: get_book, get_toc and search read paths join user/list_docs/note round-trip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 916e8b4511
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| schedule: | ||
| - cron: '0 2 * * 1' | ||
| pull_request: | ||
| types: [labeled, synchronize] |
There was a problem hiding this comment.
Because this workflow checks out the PR revision and later passes YUQUE_MCP_TEST_TOKEN into npx vitest, keeping the synchronize trigger means that once a real-api label is applied, every subsequent push to that same PR runs new, unreviewed code with the secret available on same-repository PRs. A contributor can wait for approval, then push a test or script that reads the token; remove synchronize, clear the label on new commits, or gate each SHA through an environment/manual approval before running with secrets.
Useful? React with 👍 / 👎.
npm run new:tool -- <domain> <yuque_tool_name> creates a gate-passing tool stub and placeholder test for new domains, prints a paste-ready snippet for existing domains without touching their files, rejects duplicate tool names, and always prints the remaining delivery checklist mirroring docs/workflows/add-tool.md. Turns the add-tool recipe from a document agents must follow into a procedure the harness executes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New Tool Request issue template captures a deliverable spec (tool name, upstream endpoint, access type, parameter table, acceptance criteria, out-of-scope check) so agents can implement directly from the issue. Feature Request gains an optional acceptance criteria field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
feat: tool scaffold and structured requirement intake
1 participant
Summary
Stacked on #79. Builds the harness up so a less capable agent can reliably run the full requirement → develop → test → verify → PR loop. The theme: convert judgment into procedure, convert convention into machine checks.
npm run check= lint + format:check + typecheck + test + build. "Done" is now exit code 0 of one command, and CI runs the same command so local and CI feedback cannot drift..nvmrcpins Node; AGENTS.md documents environment bootstrap (npm cifirst, and on anycommand not found).tests/mcp/capability-scope-docs.test.tsdiffs the tool list and the declared "N 个 MCP tools" count indocs/capability-scope.mdagainst the livetools/listregistry. The "update the doc when you change the surface" rule no longer relies on discipline. Verified negatively: injected doc drift fails with a message telling the fixer exactly what to update.tool-registry-contract.test.tsassertions now say, on failure, what to update if the change is intentional (contract tables, call-contract tests, capability-scope doc, breaking-change declaration) and what was broken if not.docs/workflows/{add-tool,modify-tool,fix-bug}.mdgive exact file-by-file recipes for the three dominant change types, including the breaking-change rubric. Linked from AGENTS.md and docs/README.md..github/workflows/real-api-smoke.ymlruns read-path real-API smoke via workflow_dispatch, weekly schedule, or a maintainer-appliedreal-apiPR label (labeling permission is the authorization gate). Smoke coverage grows 3 → 6 cases (adds get_book, get_toc, search). Write paths are never enabled in CI.Maintainer setup required (cannot be done from the repo)
YUQUE_MCP_TEST_TOKEN(optionally repo variableYUQUE_REAL_REPO_ID)real-apilabelmain(require PR + green CI) and CODEOWNERS for enforced human reviewTest plan
npm run checkgreen end-to-end (184 passed, 6 real-api skipped by design)capability-scope.md(wrong count + renamed tool) — sync test fails with guiding messages; restored and green againYUQUE_REAL_API=1); shape-verified against formatter output (array for toc/search, id/namespace object for get_book) — real run pending CI secret setupnpm run test:coverageand both smoke scripts unaffected🤖 Generated with Claude Code