Switch docs-generate.yml to git-based distribution, unblocking OpenWiki - #33
Merged
Conversation
@crewcircle/docs-gen still isn't publishable to npm — the org exists but publishes 404 with a permission-flavored error even after fixing the npm CLI version bug (confirmed via a real retry: same class of error, worse diagnostics). Rather than keep blocking OpenWiki generation on an unresolved npm/token issue, this checks out crewcircle-website directly in the reusable workflow, builds packages/docs-gen from source (npm install && npm run build, standalone — verified it doesn't need the monorepo root/workspace context), and invokes dist/cli.js with node instead of `npx @crewcircle/docs-gen`. openwiki itself is unaffected by any of this — it's a normal published third-party package and continues to be npx-installed from the real registry, same as before. No changes needed to the CLI itself: it already resolves its own template files via import.meta.url (relative to the script) rather than process.cwd() (the invocation directory), so running it via a separate checkout+build works the same as running it via npx would have. Verified locally end-to-end (build standalone in an isolated copy, run the CLI from a separate directory): openwiki installs correctly via npx, INSTRUCTIONS.md gets written to the right place with the right content, and it fails at exactly the expected point (missing OPENROUTER_API_KEY, which is a real secret in the actual CI environment, not present here). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Confirmed via a real CI run (git-based distribution branch): the literal-cheapest model choice hits a persistent 429 from its backing provider, Novita's shared non-BYOK pool. Happened twice in a row, not transient. Switched to mistralai/mistral-nemo — a first-party lab on OpenRouter rather than a shared-pool aggregation, negligibly pricier ($0.019/$0.03 vs $0.01/$0.03 per M tokens), same tool-calling support. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The first successful run with mistral-nemo produced only a skeleton
openwiki/index.md ("# Files", no content) and no other pages. Its own
reasoning trace: it looked at recent git log (my session's unrelated
commits), incorrectly concluded the wiki was "already current", and
never did the actual documentation pass — despite openwiki/ not
existing before this run at all. Testing whether a moderately stronger
model (qwen3-30b, still cheap, 262k context) follows OpenWiki's own
init-vs-update decision logic more reliably. If this also produces a
stub, the real fix is likely in docs-gen's own CLI (it pre-creates
openwiki/INSTRUCTIONS.md before invoking openwiki, which may itself be
enough to make openwiki think a wiki partially exists and take the
incremental-update path instead of full generation).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmed via a real, successful CI run: full first-pass generation producing accurate, substantive documentation (openwiki/quickstart.md correctly summarized the actual admin architecture from AGENTS.md). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
@crewcircle/docs-genstill isn't publishable to npm — the org exists, and the npm-CLI-version bug is fixed, but publishing still 404s with a permission-flavored error. Rather than keep OpenWiki generation blocked on that unresolved npm issue, this switches the reusable workflow to build the package from source instead of installing it from the registry:crewcircle-websiteinto a second path (docs-gen-src, sparse-checked-out to justpackages/docs-gen)npm install && npm run buildthere — verified standalone (no monorepo root/workspace needed)dist/cli.jsdirectly withnode, from within the target repo's own checkout, instead ofnpx @crewcircle/docs-genopenwikiitself (the third-party tool) is unaffected — it's a normal published package and still getsnpx-installed from the real registry as before. No CLI code changes needed: it already resolves its own template files viaimport.meta.url(relative to the script) rather thanprocess.cwd(), so running it via checkout+build behaves identically to running it vianpx.Verification
Tested locally end-to-end before pushing:
packages/docs-gento an isolated directory (no monorepo context) —npm install && npm run buildsucceeded standalone.openwikiinstalled correctly vianpx,openwiki/INSTRUCTIONS.mdwas written with the correct engineering-mode content, and the run failed at exactly the expected point: missingOPENROUTER_API_KEY(a real secret in actual CI, not present in my local shell).Test plan
OPENROUTER_API_KEYsecret — will trigger viaworkflow_dispatchright after this merges🤖 Generated with Claude Code