Repository navigation
chore(deps): bump next from 16.1.4 to 16.1.6 - #74
Merged
Merged
Conversation
Bumps [next](https://github.com/vercel/next.js) from 16.1.4 to 16.1.6. - [Release notes](https://github.com/vercel/next.js/releases) - [Changelog](https://github.com/vercel/next.js/blob/canary/release.js) - [Commits](vercel/next.js@v16.1.4...v16.1.6) --- updated-dependencies: - dependency-name: next dependency-version: 16.1.6 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Sep 7, 2026
This was referenced Sep 7, 2026
os-bill
pushed a commit
that referenced
this pull request
Sep 7, 2026
`crm_opportunity.approval_status` and `approved_date` are audit stamps written by exactly one thing — the `runAs: 'system'` approval flow — and until now they were also editable by anyone with the record open. The #1435 writer-privilege audit established the census and #1666 ruled on it (director seat, decision batch #74, 2026-09-07): declare both `readonly: true`. Nothing loses a write. `opportunity_approval` declares `runAs: 'system'` and `opportunity_approval_on_create` inherits it by spreading that flow, so `resolveRunDataContext` hands the engine `isSystem: true` and the strip branch (`if (!opCtx.context?.isSystem)`) is skipped outright. The `approval` node's own `approvalStatusField` write runs inside those same system runs. Seeds write on INSERT, which the strip never touches. No view, page or action writes either column — `grep` over `src/views/`, `src/pages/` and `src/actions/` returns nothing for both names. What IS given up, on purpose and by the ruling: an admin unsticking a wedged approval by typing over the stamp. A stuck approval is a platform or flow defect to be fixed as one, not a reason to keep an audit stamp hand-editable. There is deliberately no bypass and no admin-only branch here. The note above the two fields no longer says the fields "COULD" be declared — #1670 had already replaced the false "the platform drops writes to readonly fields" reason with a per-writer census, so what this commit changes is the verdict at the end of that census, not a stale sentence. `opportunity.hook.ts`'s `APPROVAL_FIELDS` allow-list is comment-only here, and the comment now says why the allow-list and the readonly declaration are not in tension: elevation is not anonymity (objectstack#5494). One approval write is read by two guards keyed on different halves of the same context — the freeze guard on `ctx.user?.id`, which a system run still carries, and the engine's strip on `isSystem`, which is true. Both fire as designed; neither mechanism changes. `test/audit-stamp-readonly.test.ts` pins the conjunction that makes the declaration mean something: the shipped `mark_approved` / `mark_rejected` nodes, run at the shipped flow's own `runAs` over a real ObjectQL on the real schema, still land their stamps; a plain user-context UPDATE of either column is stripped while a control column lands. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YKN9TPqDSSXUaYqp2j7MZ
os-bill
pushed a commit
that referenced
this pull request
Sep 7, 2026
`crm_campaign_member.added_date` records when a membership was created. Every writer of it is an INSERT — `campaign_enrollment`'s `create_campaign_member` and `create_contact_member` nodes, plus the marketing seed — and the readonly strip is an UPDATE-path rule, measured as such in `test/readonly-write-semantics.test.ts` and re-confirmed here on the shipped schema. There is no `update_record` node, no hook and no action that writes it. So `readonly: true` costs no writer its write, and #1667 ruled it (director seat, decision batch #74, 2026-09-07). ⭐ This is the same PRINCIPLE as #1666 but was never the same DECISION, and the R53 grading is worth keeping in view: #1666 gave up a real escape hatch — an admin unsticking a wedged approval by hand — while this card had none to give up, because hand-editing an enrollment timestamp is not a credible business action. The maintainer could coherently have ruled the two differently. They did not; both are A. The note above the field kept its per-writer census (#1670 already replaced the false 16.x reason with one) and changes only its verdict: COULD be declared → IS declared. Two cross-references this change would otherwise leave false are repaired in the same commit, because they cite this very column: * `crm_event_attendee.invited_date` said it was open "for the same reason `crm_campaign_member.added_date` is open". That reason is now inverted, and the mechanism it named never reached an insert anyway. The note now says what actually holds that column open — nobody has ruled on it — and warns against flipping it on the strength of a sibling ruling. * `crm_account.last_activity_date` cited `added_date` as "same reasoning, same shape". It is the opposite shape: `last_activity_date` is an UPDATE through a hook's `ctx.api`, which is the one shape that genuinely cannot be readonly. The rule stated there is unchanged and still load-bearing; only the false twin is retired. `test/audit-stamp-readonly.test.ts` gains the #1667 half: the two shipped create nodes still carry `added_date: '{NOW()}'` and are still `create_record`; the shipped `create_campaign_member` node, run at the enrollment flow's own (unelevated) `runAs` over a real ObjectQL, still stamps the column on INSERT; and a user-context UPDATE of it is stripped while a control column lands. The node finder walks every nested region rather than a fixed key list, so a writer that moves between region kinds cannot make these pins pass by finding nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YKN9TPqDSSXUaYqp2j7MZ
zhuangjianguo
pushed a commit
that referenced
this pull request
Sep 9, 2026
…erence_to` key
`FieldSchema` has no `reference_to` key; the canonical spelling is `reference`,
and every lookup in this tree is authored through `Field.lookup(...)`. AGENTS.md
named the retired key at three sites, which is why the brief derived from it
taught the same key.
Measured at this commit against the pinned @objectstack/spec 17.3.0:
`FieldSchema.safeParse({type:'lookup',reference_to:'crm_account'})` fails with
`unrecognized_keys` and the engine's own "Did you mean `reference_to` ->
`reference`?" receipt. `reference_to` has zero occurrences in
`src/objects/*.object.ts` (18/18 files use `Field.lookup(...)`).
Sites re-derived by text at this commit: `:62`, `:141`, `:348` (the ruling's
`:284` had moved to `:348`). Control: `masterDetail` returns 3 lines, so the
zero on `reference_to` is a real zero. No other sentence in the file moves.
Refs #1686
Ruling: decision batch #74
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017FzrA1G4U89KEMf7wfLmqq
zhuangjianguo
pushed a commit
that referenced
this pull request
Sep 9, 2026
…sing factory, named export
The Data Modeler brief taught a definition shape this repo does not have and the
spec does not accept: a root import, an `as ObjectSchema` cast, a default export,
and a raw `reference_to` key on the lookup example.
Measured at this commit against the pinned @objectstack/spec 17.3.0, with tsc
itself as the witness for the import half:
$ tsc --noEmit # on the brief's own two lines
error TS2305: Module '"@objectstack/spec"' has no exported member 'ObjectSchema'.
The root exports neither a value nor a TYPE by that name, so the taught `as`
cast could never have compiled. `@objectstack/spec/data` exports it as a
function whose `.create` is a function. The ruled replacement type-checks clean
(tsc exit 0) and `ObjectSchema.create(...)` parses at runtime.
All 18 `src/objects/*.object.ts` files agree, and agree exactly: 18/18 carry the
identical line `import { ObjectSchema, Field } from '@objectstack/spec/data';`,
18/18 call `ObjectSchema.create(`, 18/18 export a named `const`, and 0/18 use a
default export. `src/objects/index.ts` re-exports each by name — `export {
Contract } from './contract.object';` — which is why the export must be named.
The lookup example now teaches `Field.lookup('crm_account', { ... })`, the only
form in the tree (58 calls). It emits `reference`, never `reference_to`.
Refs #1686
Ruling: decision batch #74, items 1 and 3
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017FzrA1G4U89KEMf7wfLmqq
This branch was successfully deployed
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
1 participant
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.
Bumps next from 16.1.4 to 16.1.6.
Release notes
Sourced from next's releases.
Commits
adf8c61v16.1.6098c0c0[backport][ci] Make gh auth status optional when triggering a release (#89100)a43df32Backport/docs fixes jan 25 16.1.x (#89124)d6d5734tweak LRU sentinel cache key (#89123)4324698backport: implement LRU cache with invocation ID scoping for minimal mode res...23c4649[backport] Upgrade to swc 54 (#88207) (#89103)acba4a6v16.1.5e1d1fc6Add maximum size limit for postponed body parsing (#88175)500ec83fetch(next/image): reduce maximumResponseBody from 300MB to 50MB (#88588)1caaca3feat(next/image)!: addimages.maximumResponseBodyconfig (#88183)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)