Upgrade pi-ai to 1.0.0

[pkieltyka]

Summary

Bumps @earendil-works/pi-ai from 0.87.1 to 1.0.0 (0.99.0 → 0.99.1 → 0.99.2 → 1.0.0; there were no 0.88–0.98 releases) and fixes the two breakages it introduced.

• typesafe provider: pi 1.0.0 adds a provider that only serves classifier models. Added its TYPESAFE_API_KEY row to the hand-copied credential table in src/provider/pi-ai-models.ts, which the registry coverage test enforces.
• provider login openai regression: the openai provider gained "Sign in with ChatGPT" OAuth, so a bare codegenie provider login openai now takes the OAuth branch. That branch threw Sign in with ChatGPT requires a device ID because codegenie didn't pass LoginOptions.getDeviceId. Login now supplies a stable UUID, created on first use at $CODEGENIE_HOME/device-id (permissions 0600) and reused after. This matches how pi's own CLI does it.

Behavior change

Bare codegenie provider login openai now starts Sign in with ChatGPT, matching pi 1.0.0. --api-key still prompts for an API key, which is what the README already documents.

Not adopted

The other new pi 1.0.0 features were reviewed and left out on purpose:

• codemode, pi-durable, pi-mcp
• Jev classifier models
• the lightweight pi-ai/models entrypoint
• strict constrained sampling, which would fall back to non-strict on every Anthropic submit schema anyway

Test plan

• pnpm run typecheck
• vitest run: 1585 passed, including a new test that login gets a stable, persisted device id
• Manual: codegenie provider login openai completes a real Sign in with ChatGPT

🤖 Generated with Claude Code

[github-actions]

🧞 Codegenie Review

Warning

Review completed with unresolved questions. 3 question(s) remain unresolved; absence of a confirmed finding does not establish safety.

0 confirmed findings retained from completed work. Unresolved questions require attention.

Coverage

Reviewed 9/14 hunks.
Excluded by configuration/planning: 5 hunks.
Coverage levels: deep 3, normal 2, light 4, skip 5.

• pnpm-lock.yaml: lockfile

🙋 Needs Human Attention

• Does getOrCreateDeviceId rewrite an existing device-id file whose permissions are already looser than 0600 (writeFileSync mode applies only on creation), e.g. after a malformed/world-readable file is rewritten?; If an existing device-id file has loose permissions and invalid content, writeFileSync's mode is ignored on an already-existing file, so the rewritten id keeps the old (possibly 0644) mode; is tightening permissions required for this non-secret installation id?; Is the malformed/non-UUID existing device-id file path in getOrCreateDeviceId (regeneration branch) exercised anywhere, or only the happy path at tests/phase4-skills-provider.test.ts:922-940?; Should the new device-id test also assert the 0600 file mode promised in the PR body ("permissions 0600"), given writeFileSync's mode only applies when the file is created?

  • Files: src/provider/provider-services.ts, tests/phase4-skills-provider.test.ts
  • Symbols: UUID_PATTERN, getOrCreateDeviceId, supplies a stable installation device id to OAuth login
  • Reason: Packet reviewer could not resolve this question from the reviewed context. Grouped from 4 related hints across 4 packets.

• Does pi-ai 1.0.0's env-api-keys table map provider id "typesafe" to exactly ["TYPESAFE_API_KEY"] (no OAuth/bearer-token variant that should precede it)?

  • Files: src/provider/pi-ai-models.ts, tests/model-resolution.test.ts
  • Symbols: API_KEY_ENV_VARS, getPiApiKeyEnvVarName, getPiApiKeyEnvVarNames
  • Reason: The registry coverage test at tests/model-resolution.test.ts:45 only asserts each upstream provider has a non-empty name list or an ambient note; it never compares the hand-copied env var strings against pi's table. A misnamed TYPESAFE_API_KEY would therefore pass CI while getPiApiKeyEnvVarName routes the github-action LLM_API_KEY into an env var pi never reads. Upstream pi sources are not tracked in this repo, so the name could not be confirmed locally.

• Does the device-id file end up with mode 0600 on disk when $CODEGENIE_HOME/device-id (or paths.home itself) already exists with looser permissions, given that writeFileSync's mode option applies only when the file is created?

  • Files: src/provider/provider-services.ts
  • Symbols: commandLogin, createProviderServices, randomUUID
  • Reason: The only changed line in this packet is the randomUUID import; the actual device-id creation/read logic lives in hunks not included here, so persistence permissions and the stale/empty-file reuse path could not be verified.

Stats

• 🤖 Model: anthropic claude-opus-5 high
• 🧞 Codegenie: v0.7.0 (1f79ecd5a7)
• Elapsed time: 2m 21s
• Git: 0xPolygon/codegenie from master to pi-upgrade (753c44dc29)
• Review completeness: complete.
• Usage: model calls 29, tokens 556066, cost $2.0739.
• Effective caps: tokens 8000000.
• Local context pressure: 4 degraded tool results.

No confirmed findings

No confirmed findings were retained. The limitations above prevent a clean conclusion.

— View Workflow Job