Skip to content

docs: Frigg 2.0 release notes and migration guide - #660

Open
seanspeaks wants to merge 8 commits into
nextfrom
docs/2.0-release-notes
Open

seanspeaks wants to merge 8 commits into
nextfrom
docs/2.0-release-notes

Conversation

@seanspeaks

@seanspeaks seanspeaks commented Oct 1, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Reframes the Frigg 2.0 release notes and migration guide around the decided story: "Frigg 2.0: the integration backend for people and their agents." The notes now cover everything that ships in 2.0.1 by decision, including work in PRs that are still open (listed below). Every API name, config key, route, and command was checked against the PR branches.

  • docs/getting-started/whats-new-in-2.0.md opens with the one-sentence story and a short Left Hook dogfooding note. It then has five pillar sections with verified examples:

    • three ways to define an integration, one runtime, with a defineIntegration snippet and a JSON document snippet;
    • connections agents can use without seeing a credential (Management API v2, adopter JWT, memberships, entity scopes, roles, the entity proxy);
    • the product and operations profiles;
    • production by default;
    • more than one host.

    After those come a short "Under the hood" section (the earlier seven themes, condensed), breaking changes, a requirements table, and "What's next".

  • docs/guides/migrating-to-2.0.md changes only where the 2.0.1 scope changes steps:

    • Node.js 22.13+/24 and osls 4;
    • frigg validate and the renamed management values;
    • module credential encryption;
    • a new step 7 for Management API v2: v1 keeps working, a pointer to the v1→v2 table in docs/reference/api-reference.md, the adopter-JWT option, and entity scopes that keep 1.x behavior by default.

    Later steps are renumbered and the checklist is extended.

Dependencies (what the notes describe, by pillar)

1. Three ways to define an integration

2. Connections agents can use without seeing a credential

3. Two app profiles

4. Production by default

5. More than one host

Claims I changed or could not verify

Test plan

GitHub Release body for v2.0.1 (applied with gh release edit after the release)

Frigg 2.0: the integration backend for people and their agents

With Frigg 2.0, each person and each organization connects their own accounts once. People, your product, and the agents working for them then use those connections through one versioned API, and nobody outside Frigg ever holds the credential.

2.0.1 is the first stable 2.x release. Install ^2.0.1. Do not use ^2.0.0, which can resolve to a deprecated 2024 build of @friggframework/core.

Read the full overview in What's New in Frigg 2.0.

We run it ourselves. Left Hook, the company that maintains Frigg, runs both app profiles on 2.0:

  • an internal agent tool server with hundreds of tools, where every person's connections live in Frigg instead of in shared environment variables (operations profile, on Netlify);
  • a product where customers' integrations are built from a catalogue or by chat and validated by Frigg (product profile, on AWS).

Three ways to define an integration, one runtime

  • Code: an IntegrationBase class with static Definition, or one defineIntegration({ ... }) call (ADR-054).
  • A JSON document (ADR-063). Frigg checks it against a JSON Schema and against the capability manifests of the real API modules. Each published version is immutable. A document installs, lists, routes, and logs like code. extendIntegrationClass() lets code embed a document.
  • A catalogue entry. GET /api/integration-definitions lists what your app offers, and workspaces can publish their own.
  • Workflows can delay and wait for an approval. A sync engine handles one-way and two-way syncs. Definition.triggers adds recurring triggers with per-installation intervals (ADR-055). previewWorkflow() dry-runs a workflow, and previewSurface() renders UI as Slack, HubSpot, or HTML.

Connections agents can use without seeing a credential

  • Management API v2 under /api/v2/*, with GET /api/meta for discovery. Entities never return credential fields, and credentials are masked (ADR-053).
  • v1 is frozen and deprecated, and still works. Responses carry Deprecation headers. Turn v1 off with managementApi: { v1: false } once nothing calls it.
  • Adopter-token (JWT) auth with user.authModes.adopterJwt. Organization memberships let one person act in several organizations. Organization roles gate changes to shared connections.
  • Entity scopes: individual, organization, or global, with ownership rules. The default keeps 1.x behavior. Credentials are scoped through their entities.
  • The locked-down entity proxy: POST /api/v2/entities/:entityId/proxy calls the connected account's API with the stored credential. It is off by default, each module allows only the paths it lists, the host always comes from the module, named base URLs are supported, and managementApi.proxy.scopes controls whose connections it may use (ADR-052).
  • App-level entity registry: appDefinition.entities lets people connect modules that no integration uses (ADR-059).
  • Bearer tokens resolve to the token's owner. Entities can be attached to and detached from an existing integration.

Two app profiles

  • Product: many customers in one shared deployment, each workspace isolated.
  • Operations: one company or household, with connections shared by the organization and personal ones side by side (ADR-056).

Production by default

  • Encryption fails closed in every deployed stage, dev included. A deployed function without a key refuses to start (EncryptionConfigurationError). Opt out only with fieldLevelEncryptionMethod: 'none'.
  • API module credentialFields are now actually encrypted. Reads decrypt only exact ciphertext, so stored plaintext stays readable.
  • frigg init writes a working scaffold that costs about $1 a month idle: no VPC, no NAT gateway, your own PostgreSQL, and KMS encryption.
  • frigg validate, backed by an app-definition schema that matches the runtime (ADR-051). build and deploy run it first.
  • Deploys move to osls 4, and the CLI needs Node.js 22.13+ or 24 (ADR-050).
  • Rate-limit awareness: static rateLimit on API modules, Retry-After handling, and queue messages deferred to their retry time (ADR-049).

More than one host

  • AWS by default.
  • Netlify as a second provider: set provider: 'netlify' (ADR-028).

Under the hood

  • A Prisma data layer for PostgreSQL, MongoDB, and DocumentDB, with field-level encryption by KMS or AES.
  • frigg doctor, repair, generate-iam, SSM offload, structured JSON logs, and opt-in OpenTelemetry and usage counters.
  • Admin scripts and reports run inside your VPC.
  • Single-flight token refresh, a grace retry on 401, and atomic config and process-metric writes.
  • Integration extensions, one-time scheduled jobs, delivery.isLastAttempt, queryMappings, and frigg auth.

Breaking changes

  • Mongoose is removed. Core no longer exports mongoose, the Mongoose models, connectToDatabase, createFriggBackend, ModuleManager, Auther, or IntegrationFactory.
  • You set the database engine explicitly. DATABASE_URL is only the connection string and replaces MONGO_URI.
  • Integration classes use static Definition and this.events. One User model with a type field replaces the discriminators. Integrations start in IN_CREATION and pass through IN_DELETION.
  • Every deployed stage must have an encryption key, dev included. BYPASS_ENCRYPTION_STAGE is no longer read.
  • Module credential fields are encrypted on write.
  • The v1 Management API is deprecated. It still works, but v1 POST /api/integrations now checks that the caller owns every entity.
  • New migrations add organization memberships, organizationId on entities and integrations, and the integration-definition tables.
  • The app definition is validated. Unknown keys and retired management values stop build and deploy. Set user.usePassword and user.authModes explicitly.
  • The CLI needs Node.js 22.13+ or 24. Deploys use osls 4 and infrastructure.js. AWS SDK v3 replaces v2.

Upgrade

Follow the 1.x to 2.0 migration guide. It links to the v1 to v2 route table.

npm install @friggframework/core@^2.0.1
npm install -D @friggframework/devtools@^2.0.1
npm install @prisma/client@^6.19.3 prisma@^6.19.3

What's next

These are not part of 2.0.1:

  • Two-way sync written in one defineIntegration file.
  • Profile-aware frigg init and a default UI for each profile.
  • Capabilities exposed as MCP tools, an agent harness, and integration templates.
  • Admin routes for global entities.

Thanks

Thank you to everyone who filed issues, reviewed pull requests, and ran the 2.0 prereleases in production.

🤖 Generated with Claude Code


Note

Low Risk
Documentation-only changes with no runtime or config behavior; risk is limited to inaccurate upgrade guidance for adopters.

Overview
Adds Frigg 2.0.1 documentation to the GitBook nav: docs/SUMMARY.md now links What's New in Frigg 2.0 and Migrating from 1.x to 2.0.

whats-new-in-2.0.md is new release notes framed as the integration backend story, but scoped to what ships in 2.0.1 (Prisma, static Definition, frigg validate/init, ops tooling, connection reliability). It calls out breaking changes, install ^2.0.1 (not ^2.0.0), requirements, and an In review, not in 2.0.1 yet section so agent/Management API v2/Netlify-style work is not presented as released.

migrating-to-2.0.md is a new 10-step upgrade guide (Node 22+, fresh or in-place backend, explicit DB engine, frigg db:setup/validate, porting integrations and data access, optional adopter JWT, SDK v3, data migration options, deploy/verify) plus prerelease deltas and a checklist.

Reviewed by Cursor Bugbot for commit d5e77cf. Bugbot is set up for automated code reviews on this repo. Configure here.

Summary

Reframes the Frigg 2.0 release notes and migration guide around the decided story: "Frigg 2.0: the integration backend for people and their agents." The notes now cover everything that ships in 2.0.1 by decision, including work in PRs that are still open (listed below). Every API name, config key, route, and command was checked against the PR branches.

  • docs/getting-started/whats-new-in-2.0.md opens with the one-sentence story and a short Left Hook dogfooding note. It then has five pillar sections with verified examples:

    • three ways to define an integration, one runtime, with a defineIntegration snippet and a JSON document snippet;
    • connections agents can use without seeing a credential (Management API v2, adopter JWT, memberships, entity scopes, roles, the entity proxy);
    • the product and operations profiles;
    • production by default;
    • more than one host.

    After those come a short "Under the hood" section (the earlier seven themes, condensed), breaking changes, a requirements table, and "What's next".

  • docs/guides/migrating-to-2.0.md changes only where the 2.0.1 scope changes steps:

    • Node.js 22.13+/24 and osls 4;
    • frigg validate and the renamed management values;
    • module credential encryption;
    • a new step 7 for Management API v2: v1 keeps working, a pointer to the v1→v2 table in docs/reference/api-reference.md, the adopter-JWT option, and entity scopes that keep 1.x behavior by default.

    Later steps are renumbered and the checklist is extended.

Dependencies (what the notes describe, by pillar)

1. Three ways to define an integration

2. Connections agents can use without seeing a credential

3. Two app profiles

4. Production by default

5. More than one host

Claims I changed or could not verify

Test plan

GitHub Release body for v2.0.1 (applied with gh release edit after the release)

Frigg 2.0: the integration backend for people and their agents

With Frigg 2.0, each person and each organization connects their own accounts once. People, your product, and the agents working for them then use those connections through one versioned API, and nobody outside Frigg ever holds the credential.

2.0.1 is the first stable 2.x release. Install ^2.0.1. Do not use ^2.0.0, which can resolve to a deprecated 2024 build of @friggframework/core.

Read the full overview in What's New in Frigg 2.0.

We run it ourselves. Left Hook, the company that maintains Frigg, runs both app profiles on 2.0:

  • an internal agent tool server with hundreds of tools, where every person's connections live in Frigg instead of in shared environment variables (operations profile, on Netlify);
  • a product where customers' integrations are built from a catalogue or by chat and validated by Frigg (product profile, on AWS).

Three ways to define an integration, one runtime

  • Code: an IntegrationBase class with static Definition, or one defineIntegration({ ... }) call (ADR-054).
  • A JSON document (ADR-063). Frigg checks it against a JSON Schema and against the capability manifests of the real API modules. Each published version is immutable. A document installs, lists, routes, and logs like code. extendIntegrationClass() lets code embed a document.
  • A catalogue entry. GET /api/integration-definitions lists what your app offers, and workspaces can publish their own.
  • Workflows can delay and wait for an approval. A sync engine handles one-way and two-way syncs. Definition.triggers adds recurring triggers with per-installation intervals (ADR-055). previewWorkflow() dry-runs a workflow, and previewSurface() renders UI as Slack, HubSpot, or HTML.

Connections agents can use without seeing a credential

  • Management API v2 under /api/v2/*, with GET /api/meta for discovery. Entities never return credential fields, and credentials are masked (ADR-053).
  • v1 is frozen and deprecated, and still works. Responses carry Deprecation headers. Turn v1 off with managementApi: { v1: false } once nothing calls it.
  • Adopter-token (JWT) auth with user.authModes.adopterJwt. Organization memberships let one person act in several organizations. Organization roles gate changes to shared connections.
  • Entity scopes: individual, organization, or global, with ownership rules. The default keeps 1.x behavior. Credentials are scoped through their entities.
  • The locked-down entity proxy: POST /api/v2/entities/:entityId/proxy calls the connected account's API with the stored credential. It is off by default, each module allows only the paths it lists, the host always comes from the module, named base URLs are supported, and managementApi.proxy.scopes controls whose connections it may use (ADR-052).
  • App-level entity registry: appDefinition.entities lets people connect modules that no integration uses (ADR-059).
  • Bearer tokens resolve to the token's owner. Entities can be attached to and detached from an existing integration.

Two app profiles

  • Product: many customers in one shared deployment, each workspace isolated.
  • Operations: one company or household, with connections shared by the organization and personal ones side by side (ADR-056).

Production by default

  • Encryption fails closed in every deployed stage, dev included. A deployed function without a key refuses to start (EncryptionConfigurationError). Opt out only with fieldLevelEncryptionMethod: 'none'.
  • API module credentialFields are now actually encrypted. Reads decrypt only exact ciphertext, so stored plaintext stays readable.
  • frigg init writes a working scaffold that costs about $1 a month idle: no VPC, no NAT gateway, your own PostgreSQL, and KMS encryption.
  • frigg validate, backed by an app-definition schema that matches the runtime (ADR-051). build and deploy run it first.
  • Deploys move to osls 4, and the CLI needs Node.js 22.13+ or 24 (ADR-050).
  • Rate-limit awareness: static rateLimit on API modules, Retry-After handling, and queue messages deferred to their retry time (ADR-049).

More than one host

  • AWS by default.
  • Netlify as a second provider: set provider: 'netlify' (ADR-028).

Under the hood

  • A Prisma data layer for PostgreSQL, MongoDB, and DocumentDB, with field-level encryption by KMS or AES.
  • frigg doctor, repair, generate-iam, SSM offload, structured JSON logs, and opt-in OpenTelemetry and usage counters.
  • Admin scripts and reports run inside your VPC.
  • Single-flight token refresh, a grace retry on 401, and atomic config and process-metric writes.
  • Integration extensions, one-time scheduled jobs, delivery.isLastAttempt, queryMappings, and frigg auth.

Breaking changes

  • Mongoose is removed. Core no longer exports mongoose, the Mongoose models, connectToDatabase, createFriggBackend, ModuleManager, Auther, or IntegrationFactory.
  • You set the database engine explicitly. DATABASE_URL is only the connection string and replaces MONGO_URI.
  • Integration classes use static Definition and this.events. One User model with a type field replaces the discriminators. Integrations start in IN_CREATION and pass through IN_DELETION.
  • Every deployed stage must have an encryption key, dev included. BYPASS_ENCRYPTION_STAGE is no longer read.
  • Module credential fields are encrypted on write.
  • The v1 Management API is deprecated. It still works, but v1 POST /api/integrations now checks that the caller owns every entity.
  • New migrations add organization memberships, organizationId on entities and integrations, and the integration-definition tables.
  • The app definition is validated. Unknown keys and retired management values stop build and deploy. Set user.usePassword and user.authModes explicitly.
  • The CLI needs Node.js 22.13+ or 24. Deploys use osls 4 and infrastructure.js. AWS SDK v3 replaces v2.

Upgrade

Follow the 1.x to 2.0 migration guide. It links to the v1 to v2 route table.

npm install @friggframework/core@^2.0.1
npm install -D @friggframework/devtools@^2.0.1
npm install @prisma/client@^6.19.3 prisma@^6.19.3

What's next

These are not part of 2.0.1:

  • Two-way sync written in one defineIntegration file.
  • Profile-aware frigg init and a default UI for each profile.
  • Capabilities exposed as MCP tools, an agent harness, and integration templates.
  • Admin routes for global entities.

Thanks

Thank you to everyone who filed issues, reviewed pull requests, and ran the 2.0 prereleases in production.

🤖 Generated with Claude Code


Note

Overview
Unable to generate summary.

Reviewed by Cursor Bugbot for commit 4b56877. Bugbot is set up for automated code reviews on this repo. Configure here.

Cut: merged-on-next only (2026-10-24)

Sean approved the cut list and asked to keep the agents/capabilities vision line.

This commit rewrites whats-new-in-2.0.md and trims migrating-to-2.0.md so they only claim work merged on next. Unmerged items move to In review, not in 2.0.1 yet with ADR/PR pointers.

Kept as vision (not shipped claims):

  • Tagline: "the integration backend for people and their agents"
  • One-line pointer that typed capabilities and agent-ready connections are in review

Cut (still open / not on next): defineIntegration, Mgmt API v2 / proxy / scopes / profiles, fail-closed encryption, osls 4, Netlify host, rate limits, credentialFields encryption, and the Left Hook dogfood note that names unmerged profiles/hosts.

See cut-list-660-662.md in the Frigg Docs workspace for the full table.

Open in Web Open in Cursor 

seanspeaks and others added 5 commits October 1, 2026 16:07
Rewrite the July draft against the code on next. Fix the database
selection (DB_TYPE or Definition.database, DATABASE_URL is only the
connection string), describe reports as admin operations, and drop the
features that have not shipped. Add the shipped work the draft missed:
admin scripts, telemetry, structured logging, SSM offload, token
refresh reliability, atomic config and process updates, queryMappings,
and the final SQS attempt signal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rewrite the July draft against the code on next. The database engine
comes from Definition.database or DB_TYPE, integrations move from
Config/Options to static Definition, and data moves by a fresh database
or a scripted copy. Drop the @friggframework/ui renames that never
shipped and move the extension route change to a section for 2.0
prerelease adopters, next to the retired reporting key. Install
commands use ^2.0.1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.0.1 is the first stable 2.x release. Tell readers to install ^2.0.1,
because ^2.0.0 can resolve to a deprecated 2024 build of core.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
npm's latest tag for prisma currently points at an 8.x release candidate,
outside @friggframework/core's ^6.19.3 peer range.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@seanspeaks seanspeaks added release Create a release when this pr is merged prerelease This change is available in a prerelease. labels Oct 1, 2026

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Code review skipped — your organization has no extra usage available to pay for this review.

If your organization's extra usage balance is empty, an organization admin can add extra usage credits at claude.ai/admin-settings/usage. If its monthly spend limit was reached, an admin can raise it on the same page. If neither applies, contact Anthropic support.

Once extra usage is available, comment @claude review on this pull request, or push a new commit, to trigger a review.

@netlify

netlify Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for friggframework-org canceled.

Name Link
🔨 Latest commit d5e77cf
🔍 Latest deploy log https://app.netlify.com/projects/friggframework-org/deploys/6add59db7750d2cb0449f6ec

seanspeaks and others added 2 commits October 2, 2026 16:03
…guide

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… their agents

Rewrite What's New around five pillars: three ways to define an
integration (code, a validated document, a catalogue entry), connections
agents use without seeing a credential (Management API v2, adopter JWTs,
memberships, entity scopes, the locked-down proxy), the product and
operations profiles, production defaults, and Netlify as a second host.
Add the new breaking changes and requirements.

Update the migration guide for Node 22.13+/24 and osls 4, frigg validate,
module credential encryption, and a Management API v2 step that keeps v1
clients working and links the v1 to v2 table.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013b2UUFaQ5Lk6TFPqzRr1j7

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Code review skipped — your organization has no extra usage available to pay for this review.

If your organization's extra usage balance is empty, an organization admin can add extra usage credits at claude.ai/admin-settings/usage. If its monthly spend limit was reached, an admin can raise it on the same page. If neither applies, contact Anthropic support.

Once extra usage is available, someone with write access to this repository can comment @claude review on this pull request to trigger a review.

@cursor

cursor Bot commented Oct 24, 2026

Copy link
Copy Markdown

Group 5 review (docs) — COMMENT only (smoke)

Testing whether this agent can post review findings on the Frigg release PRs.

@cursor

cursor Bot commented Oct 24, 2026

Copy link
Copy Markdown

Group 5 review (docs) — COMMENT only (not an approval / not a formal request-changes)

Checked every claim against current next. The PR body correctly lists many open dependencies, but the published docs mostly state those features as already shipping. Rate limits are the only place that keeps an if merged hedge.

Would-approve verdict: changes needed. Do not treat as release-ready until the docs either (a) match code already on next, or (b) clearly mark each unmerged pillar as pending its PR (same pattern as the rate-limit line).

Inline findings are posted on the diff with severity + failure scenario. Docs-only; no new test failures relative to next.

(Ignore the earlier smoke “testing whether this agent can post” comment — this is the real review.)


### From a catalogue

`GET /api/integration-definitions` lists the latest published version of each

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — GET/POST /api/integration-definitions, document publishing, sync engine, previewWorkflow / previewSurface, and recurring Definition.triggers are written as current behavior. None of that surface exists on next (#692–#700 / #669 open).

Failure scenario: Client calls GET /api/integration-definitions on a 2.0.1 build from current next → 404 / no route → catalogue and document install flow described here cannot be followed.

}
```

This is abridged from `examples/pipedrive-hubspot.definition.json`. That

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — Points at examples/pipedrive-hubspot.definition.json, but that path (and any examples/ tree with definition JSON) is not on next or this branch.

Failure scenario: Reader follows “abridged from examples/pipedrive-hubspot.definition.json” → file not found → cannot verify the document shape or the lifecycle.onInstall webhook claim.


([ADR-053](https://github.com/friggframework/frigg/pull/668), #671)

* Every route lives under `/api/v2/*`. Errors share one shape, and every

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — Management API v2 under /api/v2/*, GET /api/meta, v1 Deprecation headers, and managementApi: { v1: false } are presented as shipped. On next, /api/v2 only covers reporting; there is no general Management API v2 / /api/meta (#671 / #668 open).

Failure scenario: Adopter sets managementApi: { v1: false } or probes GET /api/meta after upgrading → config key ignored / route missing → clients cannot discover versions or migrate using the steps in the migration guide.

A class that extends `IntegrationBase` with a `static Definition` works as it
did in every 2.0 prerelease. 2.0.1 adds `defineIntegration`, which builds that
class from one object
([ADR-054](https://github.com/friggframework/frigg/pull/669)):

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — defineIntegration is described as what “2.0.1 adds”, but there is no defineIntegration export or implementation on next (#669 still open; the PR body already notes this).

Failure scenario: Reader copies the snippet after installing @friggframework/core@^2.0.1 built from today’s next → require('@friggframework/core').defineIntegration is undefined → app fails at load.


* **Encryption fails closed** (#663). Every deployed stage encrypts sensitive
fields, `dev` included. A deployed function with no key refuses to start
with `EncryptionConfigurationError`. Set

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — “Encryption fails closed” / EncryptionConfigurationError / fieldLevelEncryptionMethod: 'none' are not on next. Current schema enum is only ["kms","aes"], and encryption still bypasses on dev/test/local (#663 open). Same section’s frigg validate (#666), osls 4 (#664; osls still ^3.78.0), credentialFields fix (#680), and Netlify provider (#686) are also unmerged — unlike rate limits, which correctly say “if merged”.

Failure scenario: Operator deploys a dev stage with no key expecting fail-closed startup → Lambda starts and writes plaintext (today’s behavior) → docs’ security guarantee is false. Or they set fieldLevelEncryptionMethod: 'none' → schema/runtime reject or ignore the value.

Comment thread docs/guides/migrating-to-2.0.md Outdated
the callers left to move.

* Move each call with the v1 to v2 table in the
[API reference](../reference/api-reference.md). Clients can call

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — Points readers to a “v1 to v2 table” in docs/reference/api-reference.md. That table is not present on next (the reference is still the unversioned Management API swagger).

Failure scenario: Client owner opens the API reference to remap /api/integrations → /api/v2/... → no mapping table → step 7 cannot be completed from the linked doc.

through `IN_DELETION`.
* **Encryption fails closed in every deployed stage, `dev` included.** A
deployed function without a key refuses to start. Opt out only with
`fieldLevelEncryptionMethod: 'none'`. `BYPASS_ENCRYPTION_STAGE` is no longer

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should-fix — States BYPASS_ENCRYPTION_STAGE is “no longer read”. On next, check-encryption-health-use-case.js still splits and honors BYPASS_ENCRYPTION_STAGE.

Failure scenario: Operator removes BYPASS_ENCRYPTION_STAGE believing it is inert, or leaves it set believing the docs → runtime still depends on the env var → migration checklist and behavior disagree.

Comment thread docs/guides/migrating-to-2.0.md Outdated
Unknown keys are errors. Rename retired values: `database.postgres.management`
takes `discover`, `managed`, or `use-existing`, and `vpc.management` takes
`use-existing` instead of `existing`. Set `user.usePassword` and
`user.authModes` explicitly, because their schema defaults changed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — Documents renamed management values (database.postgres.management: discover | managed | use-existing; vpc.management: use-existing). On next (post-#639), the live schema still uses create-new / existing / external for postgres and existing for VPC. Those renames live in open #666.

Failure scenario: Adopter following this guide against a build from current next writes management: 'managed' or 'use-existing' → schema validation fails (or, if #666 merges without reconciling #639’s external, the near-$0 scaffold breaks).

Comment thread docs/guides/migrating-to-2.0.md Outdated
This checks `DATABASE_URL`, generates the Prisma client, and runs migrations
(PostgreSQL) or `db push` (MongoDB and DocumentDB). The schema includes the
2.0.1 tables for organization memberships, entity and integration
`organizationId` columns, and integration definitions.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking — Claims frigg db:setup creates “2.0.1 tables for organization memberships, entity and integration organizationId columns, and integration definitions”. On next, Entity and Integration have no organizationId / scope fields, and there is no organization-memberships or integration-definitions model (#681 / #682 / definitions stack still open).

Failure scenario: Migrator runs frigg db:setup then expects membership / scope columns for step 7 → schema has neither → later scope/membership config fails or data has nowhere to land.

…ents vision

Rewrite whats-new and trim the migration guide so they only claim work on
next. Unmerged items move to In review with ADR/PR pointers. Keep the
agents/capabilities vision line as approved.

Co-authored-by: Sean Matthews <sean.matthews@lefthook.co>

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Code review skipped — your organization has no extra usage available to pay for this review.

If your organization's extra usage balance is empty, an organization admin can add extra usage credits at claude.ai/admin-settings/usage. If its monthly spend limit was reached, an admin can raise it on the same page. If neither applies, contact Anthropic support.

Once extra usage is available, someone with write access to this repository can comment @claude review on this pull request to trigger a review.

@sonarqubecloud

Copy link
Copy Markdown

Comment on lines +116 to +118
(PostgreSQL) or `db push` (MongoDB and DocumentDB). The schema includes the
2.0.1 tables for organization memberships, entity and integration
`organizationId` columns, and integration definitions.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text says frigg db:setup creates "2.0.1 tables for organization memberships, entity and integration organizationId columns, and integration definitions".
The companion whats-new-in-2.0.md lists memberships, entity scopes and integration definitions as data (ADR-063) as in review and not in 2.0.1.
The two docs contradict each other, and users cannot tell whether these tables exist in the released schema.
Fix: make the statements consistent, and drop this sentence if the schema is not shipped.

Suggested change
(PostgreSQL) or `db push` (MongoDB and DocumentDB). The schema includes the
2.0.1 tables for organization memberships, entity and integration
`organizationId` columns, and integration definitions.
(PostgreSQL) or `db push` (MongoDB and DocumentDB).

Spotted by Graphite

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

prerelease This change is available in a prerelease. release Create a release when this pr is merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants