chore: point GitHub URLs at the renamed InstaCloud repos - #214
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 12 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/commands/feedback.ts">
<violation number="1" location="src/commands/feedback.ts:7">
P3: Same rename missed two spots: line 23 still references `insta-feedback src/app.ts` (the ingest-service app the PR just renamed to instacloud-feedback), and the FEEDBACK_INGEST_TOKEN literal `insta-feedback-public-v1` is a separate API token, not a repo slug, so leave it. For consistency with this PR's goal, update the line 23 comment to instacloud-feedback.</violation>
</file>
<file name="src/env.ts">
<violation number="1" location="src/env.ts:34">
P3: The doc comment above the `skills` field (src/env.ts:24) still references the old `…insta-skills.git` slug, while this PR migrated every other reference to `instacloud-skills`. The skills tool echoes `owner/repo.git`, so it would now print `instacloud-skills.git @thing`. Update the comment to the new slug to match the PR's goal of eliminating stale repo references.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| // | ||
| // The backend is InstaCloud dogfooding itself: the "InstaCloud Agent Feedback" project runs the | ||
| // ingest service (InsForge/insta-feedback repo) on a postgres + compute pair. It is NOT the | ||
| // ingest service (InsForge/instacloud-feedback repo) on a postgres + compute pair. It is NOT the |
There was a problem hiding this comment.
P3: Same rename missed two spots: line 23 still references insta-feedback src/app.ts (the ingest-service app the PR just renamed to instacloud-feedback), and the FEEDBACK_INGEST_TOKEN literal insta-feedback-public-v1 is a separate API token, not a repo slug, so leave it. For consistency with this PR's goal, update the line 23 comment to instacloud-feedback.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/commands/feedback.ts, line 7:
<comment>Same rename missed two spots: line 23 still references `insta-feedback src/app.ts` (the ingest-service app the PR just renamed to instacloud-feedback), and the FEEDBACK_INGEST_TOKEN literal `insta-feedback-public-v1` is a separate API token, not a repo slug, so leave it. For consistency with this PR's goal, update the line 23 comment to instacloud-feedback.</comment>
<file context>
@@ -4,7 +4,7 @@
//
// The backend is InstaCloud dogfooding itself: the "InstaCloud Agent Feedback" project runs the
-// ingest service (InsForge/insta-feedback repo) on a postgres + compute pair. It is NOT the
+// ingest service (InsForge/instacloud-feedback repo) on a postgres + compute pair. It is NOT the
// control-plane API on purpose — feedback must work logged-out, unlinked, and from insta-oss,
// and a control-plane outage is exactly when we most want reports to still arrive.
</file context>
| @@ -31,12 +31,12 @@ export const ENVS: Record<EnvName, EnvHosts> = { | |||
| prod: { | |||
There was a problem hiding this comment.
P3: The doc comment above the skills field (src/env.ts:24) still references the old …insta-skills.git slug, while this PR migrated every other reference to instacloud-skills. The skills tool echoes owner/repo.git, so it would now print instacloud-skills.git @thing. Update the comment to the new slug to match the PR's goal of eliminating stale repo references.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/env.ts, line 34:
<comment>The doc comment above the `skills` field (src/env.ts:24) still references the old `…insta-skills.git` slug, while this PR migrated every other reference to `instacloud-skills`. The skills tool echoes `owner/repo.git`, so it would now print `instacloud-skills.git @thing`. Update the comment to the new slug to match the PR's goal of eliminating stale repo references.</comment>
<file context>
@@ -31,12 +31,12 @@ export const ENVS: Record<EnvName, EnvHosts> = {
api: 'https://api.instacloud.com',
mcp: 'https://mcp.instacloud.com/mcp',
- skills: 'InsForge/insta-skills',
+ skills: 'InsForge/instacloud-skills',
},
staging: {
</file context>
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Summary
The PR consistently replaces the three renamed GitHub repository slugs, with one misleading npm Trusted Publisher comment worth correcting.
Requirements context
Intent was derived primarily from the PR description: update shipped references to instacloud-cli, instacloud-skills, and instacloud-feedback without changing behavior. The README confirms the installer and environment-specific skills sources (README.md:15-20, README.md:155-161), while CONTRIBUTING documents the external skills repository (CONTRIBUTING.md:36-44). The named “Open Source InstaCloud” decision document was not linked or present locally, so it could not provide additional requirements.
Findings
Critical
(none)
Suggestion
.github/workflows/release.yml:133-135— The comment now says Trusted Publishing is configured forInsForge/instacloud-cli, but the PR description explicitly says npmjs.com still namesInsForge/insta-cliand must be updated externally. Until that change is confirmed, preserve the warning in the workflow—for example, describe the new repository as the required setting—so future maintainers do not incorrectly assume releases are ready. This is non-blocking because it does not alter workflow execution and the external action is clearly disclosed in the PR.
Information
- Software engineering/functionality: runtime installer, upgrade, and environment sources were updated consistently (
install.sh:50-57,src/commands/upgrade.ts:28-32,src/env.ts:30-40), and skills-source assertions were updated in lockstep (test/ensure-skills.test.ts:36-42,test/env-switch.test.ts:52-55). A repository-wide search found none of the three old slugs. Shell syntax, JSON parsing, andgit diff --checkpassed; the full typecheck/test gate could not run because dependencies are absent (tsc: not found). - Security: no authentication, authorization, secret handling, dependency, or untrusted-input behavior changed. The modified network destinations remain fixed HTTPS GitHub URLs (
agents-staging.sh:33-37,agents.sh:18-20). - Performance: no loops, queries, allocations, or execution patterns changed; only constant URLs and documentation were updated.
Verdict
Approved under the supplied severity rule: there are no Critical findings. The npm Trusted Publisher setting still needs external confirmation before the next release.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Summary
The PR correctly replaces the shipped GitHub repository slugs while preserving existing installer, upgrade, skills, and release behavior.
Requirements context
Intent was derived from the PR description, the repository’s AGENTS.md, and .claude/skills/developing-insta-cli/SKILL.md. The named “Open Source InstaCloud” decision document is not present or linked in this checkout, so the rename requirements were assessed against the explicit mappings in the PR description; this is not a command/flag change requiring a separate CLI-reference update.
Findings
Critical
(none)
Suggestion
.github/workflows/release.yml:117-138— The earlier job comment still says publishing uses a “GRANULAR AUTOMATION token” andNPM_TOKEN, while the newly expanded comment correctly says publishing uses OIDC with no token secret. Consider updating the earlier comment in this PR so release operators receive one consistent description of the publishing mechanism.
Information
- Software engineering / functionality: The installer repository feeds both GitHub API lookup and release downloads, the self-upgrade URL targets the renamed CLI repository, and production/staging skills values remain aligned with their assertions (
install.sh:55-64,install.sh:139-144,src/commands/upgrade.ts:28-28,src/env.ts:30-40,test/ensure-skills.test.ts:30-42,test/env-switch.test.ts:52-54). A tracked-file scan found no obsolete exactowner/reposlugs except the intentional pre-rename warning in the release workflow. Shell syntax checks, JSON parsing, andgit diff --checkpassed; the full TypeScript/test suite was not rerun because dependencies are absent and this review is constrained to read-only operation. - Security: No authentication, authorization, input handling, secret logging, dependency, or trust-boundary behavior changes are introduced. Operational URLs remain fixed HTTPS endpoints; only their repository paths changed (
agents.sh:8-20,agents-staging.sh:29-42,package.json:15-21). - Performance: No query, loop, allocation, I/O-pattern, or hot-path changes are introduced; the runtime edits are constant substitutions only (
src/commands/upgrade.ts:28-28,src/env.ts:30-40).
Verdict
Approved under the review rubric: zero Critical findings. The release-comment cleanup is non-blocking.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Summary
The implementation consistently updates the shipped GitHub repository slugs without changing CLI behavior.
Requirements context
Intent was derived from the PR description, the installer and environment documentation in README.md:13-20 and README.md:151-161, and the repository guidance in CONTRIBUTING.md:36-44. The named “Open Source InstaCloud” decision document is neither linked nor present in this repository, so the review otherwise assesses against the explicit PR description.
Findings
Critical
(none)
Suggestion
(none)
Information
- Software engineering / functionality: Runtime sources now consistently use
InsForge/instacloud-cliandInsForge/instacloud-skills, while staging correctly retains the#develref. The paired tests assert the updated production and staging skill sources (install.sh:55-63,src/commands/upgrade.ts:28-28,src/env.ts:30-40,test/ensure-skills.test.ts:36-42,test/env-switch.test.ts:45-59). A repository-wide search found no unintended old slug; its only remaining occurrence is the deliberate npm migration warning. - Security: No security-relevant behavior, authentication, authorization, secret handling, dependency, or input-processing changes were introduced. The changed runtime destinations remain fixed HTTPS GitHub endpoints (
install.sh:55-63,src/commands/upgrade.ts:28-28). - Performance: No performance-relevant changes were introduced; these are constant and documentation substitutions with no new I/O patterns, loops, allocations, or hot-path work (
src/env.ts:30-40,src/commands/upgrade.ts:28-28). - The npm Trusted Publisher repository setting remains an external operational prerequisite and cannot be changed by this PR; the workflow now documents the required
InsForge/instacloud-clivalue clearly (.github/workflows/release.yml:117-140). git diff --checkpassed. I could not independently execute the required typecheck/test gate because dependencies are absent in the review checkout (tsc: not found), and installing them would violate the read-only constraint; the static review found no inconsistency in the changed assertions (test/ensure-skills.test.ts:36-42,test/env-switch.test.ts:52-59).
Verdict
Approved: no critical findings. Per team policy, this verdict should be posted as a non-approving review comment; a human approval is still required.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Summary
A faithful owner/repo slug sweep that changes no CLI behaviour — every new slug resolves live, the full gate is green, and the two renames are confirmed to be the same GitHub repo objects rather than new repos at freed-up names.
Requirements context
No matching spec/plan found — assessing against the PR description alone. This repo has no /docs/superpowers/ and in fact no docs/ directory at all. The "Open Source InstaCloud" decision doc named in the PR body is not linked and is not in-tree. Intent was therefore taken from the PR body plus the in-repo convention docs: AGENTS.md:9-24 (pre-commit gate is npm run typecheck && npm test; command/flag changes must be mirrored in the skills submodule — not applicable here, no surface change) and CONTRIBUTING.md:39-44.
Note — this is a re-review at an unchanged head (70b6d28). The three existing reviews are all static. The most recent one (5184262638) states explicitly that it could not execute the typecheck/test gate. The delta in this round is that I ran it, plus negative controls — which overturns one of its claims (see S1).
Findings
Critical
(none)
Suggestion
S1 — software engineering / test coverage: the three release-critical slugs have no test binding at all.
install.sh:55 (REPO=), src/commands/upgrade.ts:28 (INSTALL_SH) and package.json:15-21 (homepage / repository.url / bugs.url).
This corrects review 5184262638, which cited install.sh:55-63 and src/commands/upgrade.ts:28 as covered by "the paired tests". They are not. Negative controls, both run on this head:
| Sabotage (revert to the old slug) | npm test |
npm run typecheck |
|---|---|---|
src/env.ts:34,39 only |
RED — 2 failed / 49 passed, in test/env-switch.test.ts:53-54 and test/ensure-skills.test.ts:39 |
clean |
install.sh:55 + upgrade.ts:28 + package.json:15-21 |
GREEN — 60 files, 916/916 | clean |
So src/env.ts is genuinely bound in lockstep (good — the PR body's claim about env.ts holds up), but the other three fields could silently drift back or be mangled by a future rename with zero gate. The repo already has the idiom for fixing this: test/install-banner.test.ts:10 reads install.sh off disk with readFileSync(new URL('../install.sh', ...)) and asserts on its contents. A handful of toContain('InsForge/instacloud-cli') assertions over those three files would fit existing conventions exactly.
The package.json field carries the most weight here — see S2.
S2 — functionality / release: the npm Trusted Publisher warning is correct, and package.json is the half of it this PR does fix.
.github/workflows/release.yml:134-139. Two refinements to the PR body's framing:
- This is not a regression introduced by this PR. The GitHub rename already landed — base
e2dd1bais already onInsForge/instacloud-cli— so the workflow's OIDCrepositoryclaim carries the new name today whether or not #214 merges. Correctly non-blocking for this PR. - But the PR body understates its own importance. npm's trusted-publishers documentation states that, for GitHub, "the
repository.urlfield in your package.json must match your GitHub repository exactly". Onmainright now that field saysgit+https://github.com/InsForge/insta-cli.gitwhile the repo isinstacloud-cli. This PR fixes that mismatch. So this should land before the next release, not after — and per the same doc, "trusted publishing configuration is not verified upon saving, so errors only surface during the publish attempt", which independently confirms the author's "cannot be measured through the API" caveat.
Information
I1 — verification I ran (closes the PR's one disclosed gap).
- Full gate on
70b6d28:npm run typecheck→ clean;npm test→ 60 files, 916 passed, 0 skipped. test/github-source.integration.test.ts— the file the author could not execute because it shells out togit init— ran green here, 8 tests. That also reconciles the count: the author's 908 passed + 8 skipped = the 916 seen here.- Live HTTP probes, all 200 unauthenticated:
raw.githubusercontent.com/InsForge/instacloud-cli/main/{install.sh,agents.sh,agents-staging.sh};api.github.com/repos/InsForge/instacloud-cli/releases/latest→v0.0.68;instacloud-skillsmain+develbranches andinsta/cli-reference.md+insta/SKILL.mdat both refs;codeloadtarballs at both refs (the pathnpx skills addactually takes);agents.instacloud.comandagents.staging.instacloud.com.
I2 — security: the new slugs are the same repo objects, not squatted freed names. Worth stating explicitly because src/env.ts:34,39 feeds npx skills add <slug>, which writes agent-readable instructions onto users' machines — a rename frees the old name, and the inverse mistake (pointing at a name someone else created) would be a live supply-chain hole.
| slug | repo id | old-name API path redirects to |
|---|---|---|
InsForge/instacloud-cli |
1283545871 |
/repositories/1283545871 ✅ |
InsForge/instacloud-skills |
1283545599 |
/repositories/1283545599 ✅ |
Otherwise no security-relevant changes: no new user input, no SQL/shell/HTTP built from user data (upgrade.ts:299 interpolates INSTALL_SH, a module constant, and that shape is unchanged), no secrets/tokens/PII, no auth or authorization changes, and no dependency changes — package.json's dependency blocks are untouched.
I3 — performance: no performance-relevant changes in this PR. Constant and comment substitutions only; no new I/O, queries, loops, allocations or hot-path work.
I4 — scope: release.yml:117-120 is not a slug edit, contrary to the body's "Only owner/repo slugs, across 12 files". The job-header comment was rewritten from "GRANULAR AUTOMATION token (repo secret NPM_TOKEN)" to the OIDC description. That rewrite is correct — I grepped .github/ and there is no NPM_TOKEN or NODE_AUTH_TOKEN anywhere, so the old comment described an auth mechanism the workflow stopped using. Good fix; the body just under-describes it.
I5 — stale non-URL references the sweep left behind. None are functional; listing them so a follow-up can be one pass rather than five:
src/env.ts:24— the comment still quotes"Source: …insta-skills.git @thing". Defensible as a verbatim quote of past tool output, but it now reads as a live slug.src/redact.ts:3andsrc/commands/feedback.ts:23— bareinsta-feedback, whilefeedback.ts:7was updated toinstacloud-feedback. (Aside: neitherInsForge/instacloud-feedbacknorInsForge/insta-feedbackis reachable unauthenticated, so I could not confirm that third rename actually happened. It only appears in comments, so nothing is at risk either way.)README.md:1andAGENTS.md:1— both H1s still read# insta-cli..claude/skills/developing-insta-cli/— directory name. Flagging a trap rather than asking for the rename: it is allow-listed by path at.gitignore:17under a.claude/skills/*deny rule, so renaming the directory without editing that line in the same commit silently stops the skill being tracked.
I6 — correctly not changed (checking the sweep didn't over-reach, since these look like slugs and aren't): client_id: 'insta-cli' at src/commands/auth.ts:132,167 (registered server-side), USER_AGENT at src/version.ts:13, $lib: 'insta-cli' at src/telemetry.ts:179, and the insta-feedback-public-v1 ingest token at src/commands/feedback.ts:44. Good scope discipline.
I7 — cross-repo follow-up, out of scope here. The InsForge/instacloud superproject's .gitmodules still names git@github.com:InsForge/insta-cli.git and insta-skills.git. Nothing breaks (git follows rename redirects over SSH), but the org-wide sweep isn't finished.
Verdict
approved — zero Critical findings. Posted as a non-approving comment per team policy; a human still gives the GitHub approval.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Addendum — correcting the requirements basis
My review above (5184308431), and all three reviews before it, said no spec covers this PR. That is wrong, and I can now check the PR against the spec's own checklist. Verdict is unchanged — still approved, 0 Critical — but the requirements section should read as follows.
The spec
InsForge/instacloud-oss → plans/2026-09-08-single-node-serverless-spec.md:272, section "Rename sweep (separate action item, not this spec)". It is a companion to the "Open Source InstaCloud" decision doc the PR body names (:3, :13). It was missed because it lives in another repo and the section title ("Rename sweep") doesn't match this PR's title — this repo genuinely has no docs/ or plans/ directory of its own.
That line enumerates the legs of the sweep, and names this repo's explicitly:
insta-cli/install.sh:55,agents.sh:8-20,src/commands/upgrade.ts:28,src/env.ts:34,39;insta-oss/.github/workflows/templates-build-images.yml(…); superrepo.gitmodules; docs links.
This PR against that checklist
| Spec leg | This PR | |
|---|---|---|
install.sh:55 |
REPO="InsForge/instacloud-cli" |
✅ |
agents.sh:8-20 |
lines 8, 12, 20 | ✅ |
src/commands/upgrade.ts:28 |
INSTALL_SH |
✅ |
src/env.ts:34,39 |
prod + staging skills |
✅ |
| "docs links" | README.md, CONTRIBUTING.md |
✅ |
superrepo .gitmodules |
different repo — correctly not attempted | ⬜ still open |
templates-build-images.yml / GHCR |
scoped to insta-oss, N/A here |
— |
Every leg the spec assigns to this repo is complete, at the exact line the spec names. The PR also updates agents-staging.sh, package.json and two test files, which the spec doesn't enumerate but which are the obvious siblings of legs it does — a correct reading of scope, not overreach.
Two consequences for the findings above
- I7 is upgraded from an observation to a spec-tracked item. The
InsForge/instacloudsuperproject's.gitmodulesstill readsgit@github.com:InsForge/insta-cli.gitandinsta-skills.git— I verified that live. It is an enumerated leg of this same sweep and remains open. Still correctly out of scope for a PR in this repo; it just now has a spec line behind it rather than only my say-so. - S2 gains, not loses, weight. I grepped the spec for
npm/trusted/OIDC/publish: the rename sweep says nothing about npm Trusted Publishing. So the release blocker the author surfaced in the PR body is a gap in the spec's own checklist, found by the author rather than inherited from it. Worth crediting, and worth feeding back into the sweep's tracking item so the other renamed repos get checked for the same thing.
Also note the spec's :272 GHCR caveat — "GHCR does not redirect packages, so both prefixes must resolve until every manifest is republished" — is scoped to insta-oss template images. Nothing in this repo publishes to GHCR, so no analogous constraint applies here; the npm registry is this repo's equivalent exposure, and that's exactly what S2 covers.
Verdict
Unchanged: approved — 0 Critical. The correction strengthens the case for merging: the PR is now shown to satisfy a documented checklist in full, not just its own description.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
Summary
A faithful owner/repo slug sweep with no behaviour change; merged at e40f00f while my previous round was posting, so this is a post-merge pass focused on what is newly checkable — above all the one thing the PR body says it could not measure.
Critical: none. Nothing here blocks, and nothing can — the PR is merged. Everything below is a Suggestion or Information note, most of it pointed at the next release.
State check
Merged main tip e40f00f is the only commit past the base; no revert, no follow-up commits. The merge is a squash whose tree hash is byte-identical to the reviewed head 70b6d28 (9a00c85 both), so the review carries over to main without re-derivation. I re-ran the gate on merged main anyway: tsc --noEmit clean, 916/916 across 60 files. That run includes test/github-source.integration.test.ts — the file the body flagged as unrunnable in the author's worktree — so the disclosed gap is closed: 908 passed + 8 skipped there is 916 here.
Requirements context
Spec found, in the sibling repo: InsForge/instacloud-oss → plans/2026-09-08-single-node-serverless-spec.md:272, section "Rename sweep (separate action item, not this spec)". It enumerates this repo's legs by file:line — install.sh:55, agents.sh:8-20, src/commands/upgrade.ts:28, src/env.ts:34,39 — plus the superrepo .gitmodules and docs links. All four in-repo legs land at exactly those lines.
New since the last round: the superrepo leg is now closed too — InsForge/instacloud .gitmodules names instacloud-cli / instacloud-skills (all nine submodules renamed). The only remaining item in that spec bullet is the insta-oss GHCR prefix, which was deliberately deferred in instacloud-oss#108 because GHCR does not redirect packages. The sweep checklist is complete for this repo. The spec says nothing about npm/OIDC — the item below is a gap in the sweep's own checklist, found by the author.
Findings
Critical
(none)
Suggestion
1. Functionality — the npm Trusted Publishing blocker is real, still unfired, and I can now date it precisely.
The body predicts the next npm publish fails, flagged "from the workflow's own documentation rather than measured". It is measurable after all, from the other side. insta@0.0.68's SLSA provenance records:
repository: https://github.com/InsForge/insta-cli <- OLD name
repository_id: 1283545871
gitCommit: e2dd1baf... (= this PR's base)
So the GitHub rename landed after the last publish (2026-09-11T20:53Z) and before this merge (23:54Z). Every release to date carried the old name and matched the npmjs config — which is why nothing has broken yet. The next publish is the first one whose OIDC claim says InsForge/instacloud-cli. The window is still open: main's tip is the merge commit, the newest tag v0.0.68 sits on the base e2dd1ba, package.json is still 0.0.68, and no version-bump PR is open. So the action item in .github/workflows/release.yml:134-138 is correctly stated and genuinely pending.
2. Functionality — the "not readable" caveat is right about the public API, but a maintainer can turn this into a runnable pre-flight.
GET /-/package/insta/trust returns 401 Bearer token authorization is required unauthenticated — confirmed, and with a positive control (the same endpoint for the npm package is also 401), so the body's caveat holds. But that is exactly the endpoint npm trust list reads, and it ships: lib/commands/trust/list.js is present in npm 12.0.2. As a maintainer of insta:
npm trust list insta # reads GET /-/package/insta/trust — prints the configured repo
npm trust github insta --repo InsForge/instacloud-cli --file release.yml --allow-publish
Worth folding into release.yml:134-138 and the release checklist, so "check it on npmjs.com before the next release" becomes a command someone can actually run and diff. (Per docs.npmjs.com/trusted-publishers, the config is not validated on save — errors only surface at publish time — which is precisely why a pre-flight read beats eyeballing the web UI.)
3. Functionality — this PR quietly fixes a second, independent publish blocker; the body undersells itself.
npm publish --provenance (release.yml:150) additionally requires package.json repository.url to match the building repository exactly. Pre-PR that field said insta-cli while the repo is already instacloud-cli — so even with the Trusted Publisher updated, the pre-PR tree had a second failure mode. package.json:15-21 now fixes it. Framing: this PR was a prerequisite for the next release, not merely cosmetic.
4. Software engineering — the three highest-blast-radius constants are unbound by tests. Two negative controls on the merged tree, sabotage diffs verified applied before trusting either result:
- Revert only
src/env.ts:34,39→ RED, 2 failures (test/env-switch.test.ts:53-54,test/ensure-skills.test.ts:39). Genuinely lockstep-bound, as the body claims. - Revert
install.sh:55(REPO=) +src/commands/upgrade.ts:28(INSTALL_SH) +package.json:15-21→ GREEN, 916/916, typecheck clean. Zero binding.
The unbound set is the consequential one: the installer's release-download target, the self-upgrade URL, and the very repository.url that finding 3 shows provenance validates. A silent drift back to the old slug in any of them ships. The idiom already exists in-repo — test/install-banner.test.ts:10 does readFileSync(new URL('../install.sh', import.meta.url), 'utf8') and asserts on the text. A three-line assertion on REPO=, INSTALL_SH and repository.url would close it.
Information
5. Functionality — if the publish does fail, the release lands half-shipped. publish-npm is needs: release (release.yml:121-122), so the tag, the GitHub release and the install.sh + binary assets are all uploaded before npm is touched. The failure is loud in CI (no continue-on-error on release.yml:150), but the outcome is asymmetric: installer users get the new version while npm i -g insta / npx insta@latest users stay on 0.0.68. Worth knowing when the next release goes out.
6. Software engineering — small doc nit in the comment this PR rewrote. release.yml:139 says "Needs npm ≥ 11.5"; docs.npmjs.com/trusted-publishers says 11.5.1 (and Node ≥ 22.14.0). Immaterial in practice — release.yml:140 installs npm@latest. Noting only because that comment block is in the diff. Related, and not a defect: npm@latest is now 12.0.2, whose engines are ^22.22.2 || ^24.15.0 || >=26.0.0; node-version: 22 currently resolves to v22.23.2, which fits, and v0.0.67/v0.0.68 already published successfully on that exact combination — so the unpinned @latest is empirically fine today, just a narrow window worth remembering if a future npm major drops the Node 22 line. (The comment's other claim checks out: Node 22.23.2 bundles npm 10.9.8, well under 11.5.1, so the upgrade step is necessary.)
7. Cosmetic leftovers on main. Deliberate or not, insta-cli/insta-skills/insta-feedback still appear in prose at README.md:1, AGENTS.md:1,22, CONTRIBUTING.md:57, src/env.ts:24, src/redact.ts:3, src/commands/feedback.ts:23. cubic flagged the last two as P3 and they were not addressed — fine to leave, but they are the ones a future reader will trip on. Correctly not swapped (they look like slugs but are wire identifiers): client_id: 'insta-cli' (src/commands/auth.ts:132,167), USER_AGENT (src/version.ts:13), $lib (src/telemetry.ts:179), insta-feedback-public-v1 (src/commands/feedback.ts:44).
8. A tripwire for whoever finishes the rename. .gitignore:13-17 allow-lists the tracked skills directory by path: !.claude/skills/developing-insta-cli/, and .claude/skills/developing-insta-cli/SKILL.md is the only tracked file under .claude/. Renaming that directory to match the sweep without editing .gitignore:17 lets .claude/skills/* re-swallow it and silently untracks the file. Out of scope here; flagging before someone does the obvious follow-up.
9. Security — no weakening, and the rename-specific supply-chain check passes. A rename frees the old name, and src/env.ts:34,39 feeds npx skills add <slug>, which writes agent-readable instructions onto user machines — so "same name" is not enough, the objects must be identical. All three redirect to the same repository IDs, i.e. the same objects, not re-registered squats: instacloud-cli = 1283545871 (independently corroborated by the repository_id in v0.0.68's provenance, recorded under the old name), instacloud-skills = 1283545599, instacloud-feedback = 1338764030. No new dependencies, no secrets or PII introduced, no auth path touched; release.yml:117-120 documents the NPM_TOKEN → OIDC move that already happened (no NPM_TOKEN/NODE_AUTH_TOKEN remains anywhere in .github/).
10. Backward compatibility — verified live, not assumed. Already-distributed installers hardcode the old slug, and install.sh fetches with curl -fsSL (-L follows). Old-slug releases/latest → v0.0.68; old-slug asset download → HTTP 200 (redirecting to release-assets under repo id 1283545871); old-slug raw.githubusercontent.com → 200 already serving the new content (REPO="InsForge/instacloud-cli"). agents.instacloud.com (CloudFront) has also already refreshed to the new bytes, so the up-to-a-day stale-cache window the README warns about is closed.
11. Performance — no performance-relevant changes. String constants and comments only; no query, loop, allocation or I/O path is touched.
Verdict
approved — zero Critical findings. (Informational: the human approval on this PR was already given, and it is merged.)
The one thing to carry forward: run npm trust list insta and confirm it says InsForge/instacloud-cli before cutting the next version — that is the only leg of the rename that is still open, and by finding 1 the next publish is the first one that will actually exercise it.
2 participants
Follow-up to the org-wide InstaCloud repo rename (see the Open Source InstaCloud decision
doc). This repo is now
InsForge/instacloud-cli; this PR updates the slugs it still ships.release.ymlpublishesinstato npm via OIDC trusted publishing, which matches on theGitHub repository name. The config on npmjs.com still says
InsForge/insta-cli:After the rename this workflow's OIDC claim carries
InsForge/instacloud-cli. npm does notfollow GitHub renames the way GitHub's own redirects do, so unless someone updates
npmjs.com → package
insta→ Trusted Publisher → repository toInsForge/instacloud-cli,the next
npm publishis expected to fail. That setting is not readable through the publicAPI, so this is flagged from the workflow's own documentation rather than measured — please
confirm it on npmjs.com before the next release.
Nothing is broken today: the currently published
insta@0.0.68is unaffected, and usersinstalling it are fine.
What changed
Only
owner/reposlugs, across 12 files:InsForge/insta-cli→InsForge/instacloud-cliInsForge/insta-skills→InsForge/instacloud-skillsInsForge/insta-feedback→InsForge/instacloud-feedbackTouching
install.sh(REPO=),agents.sh/agents-staging.sh(the documented rawfallbacks),
src/commands/upgrade.ts(INSTALL_SH),src/env.ts(the prod/staging skillssource),
package.json, README/CONTRIBUTING, the two tests that assert those strings, andcomments in
release.ymlandsrc/commands/feedback.ts.src/env.tsand its tests were changed in lockstep, soENVS.prod.skills/ENVS.staging.skillsand their assertions still agree.Verified live
InsForge/instacloud-skills+ itsdevelbranchinstacloud-clireleases/latestv0.0.68raw.githubusercontent.com/InsForge/instacloud-cli/main/agents.shagents.instacloud.com(CloudFront over the old raw path)Old slugs keep working regardless: GitHub redirects renames on web, git, the API, raw and
jsDelivr. This PR is about not shipping stale URLs, not about repairing breakage.
Tests
npm ci && npm teston this branch: 908 passed, 8 skipped.One file,
test/github-source.integration.test.ts, could not run in my environment — it shellsout to
git init, which my worktree-isolated session refuses. It contains zero slugreferences, so this change cannot affect it, but I did not execute it and CI should be the
judge.
🤖 Generated with Claude Code
https://claude.ai/code/session_01QtUBRLn31nL66MeXpLvpbR
Summary by cubic
Updates all shipped GitHub URLs to the renamed InstaCloud repos:
InsForge/insta-cli→InsForge/instacloud-cli,InsForge/insta-skills→InsForge/instacloud-skills, andInsForge/insta-feedback→InsForge/instacloud-feedback. This is a pure slug rename with no behavior change — the old slugs keep working through GitHub's redirects.Action needed before the next release
instastill points atInsForge/insta-cli; npm does not follow GitHub renames, so the next OIDC-basednpm publishwill fail until it's updated toInsForge/instacloud-cli.Written for commit 70b6d28. Summary will update on new commits.