* chore(rebrand): update Gitlawb references to Twigpine (#2246)
The GitHub org has been renamed to Twigpine, so point repo URLs, badges,
CI repo-identity guards, and user-facing sponsor/partner labels at the new
name.
Scope is deliberately limited to references that are safe to change today:
- GitHub URLs (github.com, api.github.com, raw.githubusercontent.com),
including the skills registry and release-please release notes
- The release-please release trigger, which gates on the repo slug and
would otherwise stop publishing
- User-visible display strings: gateway label/name, AI/ML API partner
name, sponsored-tip sponsor, and docs/site prose
Left on the old name because the rename has not landed for them:
- `@gitlawb/openclaude` npm scope (the package does not exist on npm)
- opengateway/ads/docs subdomains, which resolve only under gitlawb.com
- The `gitlawb-opengateway` preset id, tip ids, and gateway file names,
which are persisted in user config and sent on the wire
* fix(aimlapi): stop matching topup intent on partnerName (#2246)
partnerName is display metadata that travels alongside the partner id, not
part of the intent identity. It is now excluded from INTENT_KEYS, so
matchesIntent no longer requires it to be unchanged.
Without this, renaming the partner on the Gitlawb -> Twigpine rebrand would
have stranded any in-flight topup: a receipt persisted under the old name
fails the strict equality check, so loadAimlapiTopupState returns null and
the user restarts checkout. partnerId remains the identity field, so
receipts are still scoped to the correct partner.
* fix(web): use current Twigpine artwork for the partner card (#2246)
The partner asset was a byte-identical rename, so the roster row rendered
the former GitLawb key/branch symbol under the Twigpine name while the
README pointed at the official tree mark. Vendors the current artwork from
twigpine.com/logo.png, resized to the roster's 256x256 convention, keeping
the self-hosting contract in web/src/data/partners.ts.
---------
Co-authored-by: Gravirei <gravirei@users.noreply.github.com>
#1399 already fixed the specifier-collision class by tracking missing
relative imports per importer, which also resolves the WebFetch ssrfGuard
case (the test-file string literal now only stubs the test importer, never
WebFetch). The remaining gap is bundle-level coverage: the existing
security-hardening test reads source only and would pass even if the
shipped CLI bundle had stubbed the guard to a noop.
Rebase onto current main (dropping the now-redundant scanner change) and
add a dist/cli.mjs assertion alongside the /dream regression test: the real
ssrfGuard blocked-address error is present and ssrfGuard is not replaced by
a missing-module stub.
Scope missing-module stubs for relative imports to the importer file so the unmirrored KAIROS dream skill stub no longer replaces the real /dream command module during bundling.
GravireiandGravirei
Bogdan
beardthelion
chioarub