mirror of
https://github.com/dtzp555-max/ocp.git
synced 2026-07-27 07:55:07 +00:00
553c53621a31262ffc9cb01033bb4008a38aea72
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  taodengandClaude Opus 5
|
553c53621a |
ci: add a manual flake hunt for #203 (Linux x Node version)
#203 has been seen four times, always on Linux CI, never once on macOS across 1000+ runs in two independent experiments. The documented next step is a Linux + Node 24 reproduction, and there is currently no way to run one without reddening an unrelated PR and waiting for chance. workflow_dispatch only — it never runs on push or pull_request, so it costs nothing until someone asks for it. Inputs are the two suspected variables: - `node` is a choice (24 / 22 / 26) rather than pinned, because 22-vs-24 is a comparison worth running deliberately. A previous Linux VM attempt was invalidated by Node 22's `node:sqlite` ExperimentalWarning landing on stderr, which the boot gate read as "server did not start" — ~23 of 50 runs failed spuriously. The workflow says so, so the next person interprets a 22 result against that confound instead of rediscovering it. - `concurrency` is the knob that actually reproduces, not round count: test() is fire-and-forget for async bodies, so ONE suite run already spawns 15 concurrent server.mjs children across 11 ltBoot tests. Several suites at once is what multiplies cross-process contention. Classification is anchored on the failure marker AND the test name, which is not cosmetic. ltDiag samples the first 900B of child stdout (#204) — the boot banner — so a log where only the GATE test failed still contains "Local tools: ON". Validated against real logs rather than reasoned about: 3 clean runs + 1 gate-mutation run gave unanchored 'Local tools' -> 1 hit, attributed to the WRONG category anchored -> gate=1, announce=0 (correct) totals -> total=4 clean=3 (correct) My first draft had the unanchored form with a comment claiming the failure mode was "matches every log". That was wrong — the real defect is cross-category attribution, caused by the diagnostic quoting the child's own output. Found by running the logic on real logs; the comment now states the measured reason. The job does NOT fail on a reproduction: catching the flake is the goal, and a red X would read as "the hunt is broken" rather than "the flake was caught". Results go to the step summary; logs upload as an artifact. server.mjs: unchanged (CI-only; ALIGNMENT.md requires no cli.js citation). Verified: YAML parses, all three run blocks pass `bash -n`, classify logic exercised against real suite output. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017gbqUZ8HfBZpjjbzQ85oH8 |
||
|
|
a99395ed0c |
ci: fix release.yml's no-CHANGELOG path, which would have failed the release job (#202) (#206)
* ci: cover models.json in the alignment guardrail; fix release.yml's no-CHANGELOG path Two CI-layer fixes found during the v3.25.0 review. Same layer, both small, so they land together (Iron Rule 11). #198 — alignment.yml did not run on a models.json-only PR. The `paths:` filter listed server.mjs / setup.mjs / scripts / lib / ocp / ocp-connect, but not models.json. That made CLAUDE.md hard-requirement #2 ("CI blacklist pass") vacuous for exactly the PRs that change model routing: confirmed on #192, where only gitleaks and test-features ran. models.json is not inert data. It drives MODEL_MAP and VALID_MODELS, the default request model, and — since ADR 0009 — the global MAX_PROMPT_CHARS truncation budget. A models.json-only PR can therefore change server.mjs's runtime behavior with the guardrail never running. models.schema.json is included for the same reason one level up: loosening the schema is what would let a malformed models.json through. Adding paths only widens coverage; the blacklist grep still scans server.mjs, so this costs nothing and closes the gap. Per CLAUDE.md this is a PR amendment to alignment.yml, which is the sanctioned way to change it (removing entries would need an ALIGNMENT.md amendment; nothing is removed here). #202 — release.yml's no-CHANGELOG fallback would have failed the release job. The branch wrote an output named `notes` and exited WITHOUT creating /tmp/release-notes.md, while the create step hard-codes `--notes-file /tmp/release-notes.md`. So the one path that exists to "degrade to minimal notes" instead produced a failed release. Verified both directions by extracting the step's actual script from the YAML and running it, rather than reading it: PRE-FIX, no CHANGELOG -> exit 0, GITHUB_OUTPUT="notes=Release v3.25.0", /tmp/release-notes.md MISSING -> gh release create --notes-file WOULD FAIL POST-FIX, no CHANGELOG -> exit 0, notes_file set, file present ("Release v3.25.0") POST-FIX, with CHANGELOG -> file present, first line "## v3.25.0 — 2026-07-27" Fixed by writing the file in that branch, and by removing the hard-coded-path coupling entirely: both branches now set `notes_file` and the create step consumes `steps.notes.outputs.notes_file`. That output existed already and was never read — the two only agreed by accident. Also added `set -euo pipefail` (the step previously ran unset-tolerant) and an echo of the resolved notes before creating the release, so a wrong-looking body is visible in the job log instead of only on the published release. NOT changed: the empty-extraction guard. My issue text suggested adding one, but `if [ ! -s "$NOTES" ]` was already there and already handles a heading mismatch. Correcting that claim on #202 rather than taking credit for it. Both workflows re-validated as YAML. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017gbqUZ8HfBZpjjbzQ85oH8 * ci: drop the alignment.yml paths change — it would have been a green check for a check that never ran Reverting my own half of this PR. The reviewer proved the alignment.yml change was theatre, and my issue #198 was filed on a wrong premise. What I verified myself before reverting: - the alignment job BODY references models.json zero times; only the paths filter I added mentioned it - test.yml is `pull_request:` with NO paths filter, so it already runs on every PR, models.json-only ones included - on a deliberately corrupted models.json (contextWindow 1000000, a typo'd openclawName), `npm test` catches it: 455 passed, 2 failed So the real guard on models.json already existed and always ran. Adding the path would only have made a job execute that inspects nothing about models.json, and then reported a green "Alignment Guardrail" — implying a check that did not happen. That is strictly worse than the job not running, which is precisely the reviewer's point. #198's premise was also wrong. The blacklist greps server.mjs for known hallucinated tokens. A models.json-only PR cannot introduce a token into server.mjs, so CLAUDE.md hard-requirement #2 is INAPPLICABLE on such a PR, not vacuous. I read "the guardrail didn't run" as "coverage gap" without checking what the guardrail actually inspects. The release.yml half is unaffected and stays: that one is a real, reproduced failure (the no-CHANGELOG branch never wrote the file the create step consumes). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017gbqUZ8HfBZpjjbzQ85oH8 --------- Co-authored-by: dtzp555 <dtzp555@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
6dff36959a |
chore(governance): pin legacy OAuth host in alignment.yml + ALIGNMENT.md amendment (#123) (#128)
Follow-up to the 2026-05-31 audit (deferred from #112). The OAuth token host platform.claude.com/v1/oauth/token was verified against the compiled cli.js in #119; this pins the legacy WRONG host so a future accidental revert hard-fails CI. - .github/workflows/alignment.yml: add "console.anthropic.com/v1/oauth/token" to the BLACKLIST; rewrite the comment + failure message so the blacklist now documents TWO kinds of token — known hallucinations AND pinned wrong-host variants of a verified Class A endpoint (a hit means a drift, not necessarily a hallucination). The pinned token is absent from server.mjs (which uses platform.claude.com), so CI stays green. - ALIGNMENT.md: new "OAuth token-host verification (2026-05-31)" subsection recording the binary verification (claude.exe 2.1.154, strings, no live probe) and the dual-purpose blacklist policy. Purely additive; Rules / audit pin / Historical Lesson untouched. Per ALIGNMENT.md Amendment Procedure: (a) motivating evidence cited (issues #112/#119/#123), (b) independent fresh-context opus reviewer APPROVE — verified the pinned token does not trip the build (absent from server.mjs; live host not blacklisted), YAML valid, amendment consistent with the server.mjs verification comment, purely additive scope. (c) not incident-driven (a confirming verification, not a new drift) so Historical Lesson unchanged. Closes #123. Co-authored-by: dtzp555 <dtzp555@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
|
9e25160527 |
refactor: hoist port literal to lib/constants.mjs + CI gate (v3.16.4) (#98)
Closes the structural side of the port-drift cascade addressed by
v3.16.2/v3.16.3. Those releases reverted the literal line-by-line; this
one removes the invitation to drift.
Changes:
* NEW lib/constants.mjs — exports DEFAULT_PORT=3456, LOCAL_HOST,
OPENAI_API_BASE, LOCAL_PROXY_URL.
* server.mjs / setup.mjs / scripts/upgrade.mjs / scripts/doctor.mjs
(x2) / scripts/sync-openclaw.mjs all import DEFAULT_PORT from
lib/constants.mjs instead of hardcoding "3456".
* .github/workflows/alignment.yml:
- path filter extended to setup.mjs, scripts/**, lib/**,
ocp, ocp-connect.
- NEW job port-spot hard-fails any PR that introduces a hardcoded
"3478" or "3456" literal outside EXEMPT_REGEX (lib/constants.mjs,
test-features.mjs, ocp/ocp-connect bash CLIs, docs, the workflow
itself).
* Doc-comment rewording so CI grep finds zero hits.
No behavior change for any user. CLAUDE_PROXY_PORT env var still wins
at runtime; only the unset-env fallback now flows through one constant.
ALIGNMENT.md note: server.mjs change is one import + one literal swap,
mechanical. No cli.js operation changed; the citation requirement does
not apply.
cli.js: not applicable — mechanical refactor, no behavior change.
Co-authored-by: dtzp555 <dtzp555@gmail.com>
|
||
|
|
c998d21a4f |
chore(ci): add gitleaks workflow to scan PRs and pushes to main (#64)
The repo has shipped `.gitleaks.toml` (with project-specific allowlist entries — public OAuth client ID, README placeholders, an old plan doc) since the privacy remediation work, but no GitHub Action invoked it. The config was orphan: real protection only when someone ran gitleaks locally, never gating merges. This workflow wires `.gitleaks.toml` into CI: - Triggers on every `pull_request` (any branch) and `push` to `main`. - Uses `gitleaks/gitleaks-action@v2`, which auto-detects the repo-root `.gitleaks.toml` and applies its allowlist. - Hard-fails on any leak. No `continue-on-error`. Public repo policy. - `permissions: contents: read` — minimum required scope. - `fetch-depth: 0` so the action can scan full history (the action's default behavior; explicit here for clarity). Verification path: - The workflow runs on this PR itself; if any secret were ever committed to the repo, the scan fails here. Prior audit confirmed the tracked tree is clean of real secrets, so this PR's own scan should pass. Refs: audit side-finding 4 of 4. Co-authored-by: dtzp555 <dtzp555@gmail.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
|
0752f666fb |
test: wire test-features.mjs to npm test + add minimal CI smoke workflow (#60)
`test-features.mjs` shipped at v3.8.0 (per CHANGELOG of the keys.mjs quota+cache work) and is referenced from AGENTS.md as the project's only test artifact, but until now nothing actually ran it — no `npm test` script, no CI step. Wiring it up so it runs on every push and PR. ### Changes - `package.json`: add `"test": "node test-features.mjs"` to scripts. - `.github/workflows/test.yml` (new): single-job workflow that runs `npm test` on push to main and on every PR. Uses Node 24 because `keys.mjs` imports `node:sqlite`, which is stable in Node 23+ (Node 24 is the current LTS; Node 22 would need `--experimental-sqlite`). No `npm install` step — OCP has zero external runtime dependencies per `package-lock.json`. - `AGENTS.md`: note that `test-features.mjs` runs via `npm test` and is enforced by `.github/workflows/test.yml`. ### Why this is a hard check, not a soft check `test-features.mjs` is self-contained — it imports `keys.mjs` and exercises the SQLite-backed key/quota/cache code paths against a throwaway test DB at `~/.ocp/ocp-test.db`. It does NOT require: - a live claude CLI binary - a running OCP server - any network access So CI can run it as a real check; no `continue-on-error` needed. ### Local verification ``` $ npm test [...] === Results: 24 passed, 0 failed === ``` 24 assertions cover createKey / listKeys / quota math / cache hash determinism / cache TTL / clearCache. Exit code is 1 on any failure (`process.exit(failed > 0 ? 1 : 0)` at the bottom of test-features.mjs). ### Future expansion If the suite later grows to include tests that DO require a live claude CLI or a running OCP, mark those steps `continue-on-error: true` (or split them into a separate job). The comment in `test.yml` documents this contract. Refs: audit (test-features.mjs orphan / unrunnable in CI). Co-authored-by: dtzp555 <dtzp555@gmail.com> |
||
|
|
497ff1dcd2 |
chore(governance): add release-kit overlay + PR self-check + auto-release workflow (#35)
Implements cc-rules v1.4's 第五律 5.5 project overlay requirement. - CLAUDE.md: declare release_kit: YAML block (version_source, changelog, release_channel, docs_source, resource_lists, new_feature_doc_expectations, bootstrap_quirk_policy) - .github/PULL_REQUEST_TEMPLATE.md: add 5.3 user-visible-change self-check section with reviewer gate instruction - .github/workflows/release.yml (NEW): auto-create GitHub Release from CHANGELOG.md section on v* tag push. Idempotent (checks if release already exists). Closes the gap that caused v3.9.0 / v3.10.0 / v3.11.0 to each miss their GH Release. Governance-only change. No code, no user-visible behavior change (the workflow only fires on future tags). No README update needed. Co-authored-by: Tao Deng <dtzp555@gmail.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
|
2853088261 |
[Constitution] Alignment principle + CI guardrails (addresses b87992f drift) (#20)
* docs(constitution): establish OCP alignment constitution + CI guardrails (PR A) Introduces the OCP project constitution to structurally prevent the kind of scope drift that produced commit |