fix(build): pin NODE_ENV=production in the build script by joryirving · Pull Request #768 · misospace/dispatch

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving · 2026-08-14T12:45:56Z

NODE_ENV=development npm run build fails on main during prerender:

TypeError: Cannot read properties of null (reading 'useContext')
Export encountered an error on /_global-error/page: /_global-error, exiting the build.

next build always emits a production build, but when NODE_ENV=development is inherited from the caller Next resolves React through its development export condition while the compiled server bundle keeps the production one. The prerender worker ends up with two React copies, so the hook dispatcher is null on any route that renders a context — /_global-error and /automation here. The React key warnings on <html>/<head>/<meta> are the same mismatch, not a separate problem. Next itself warns about this: You are using a non-standard "NODE_ENV" value in your environment.

Not a regression from #767 — 16.3.0 fails identically. Plain npm run build has always passed, which is why repo CI is green.

Pinning NODE_ENV in the script makes the build independent of the ambient value, matching what lint, test and typecheck already do. No-op for repo CI and for the Dockerfile builder stage, both of which already build with NODE_ENV unset.

Verified at 0aa4c84 + this commit:

command	before	after
`NODE_ENV=development npm run build`	fail	pass
`npm run build`	pass	pass
`npm run typecheck`	pass	pass
`npm run lint`	pass (1 pre-existing warning)	pass
`npm run test`	2272 passed	2272 passed

This commit is unsigned. It carries the DCO Signed-off-by trailer, but the local 1Password SSH signing agent was unreachable and GitHub's contents API did not apply web-flow signing either. To re-sign before merge:

git fetch origin fix/nextjs-16-prerender-usecontext
git checkout fix/nextjs-16-prerender-usecontext
git commit --amend --no-edit -S
git push --force-with-lease

https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

`next build` always emits a production build, but Next resolves React through the "development" export condition when NODE_ENV=development is inherited from the caller. The prerender worker then loads a second React copy, and rendering fails with "Cannot read properties of null (reading 'useContext')" on /_global-error and /automation. Pinning NODE_ENV in the script makes the build independent of the ambient value, matching the existing lint/test/typecheck scripts. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_01YSuDvZq9ncvyX85Uzx3cQh

its-saffron

AI Automated Review

Full PR review.

Analysis engine: dsv4f@https://litellm.jory.dev/v1 (openai) — primary route

Recommendation

Approve. The change pins NODE_ENV=production in the build script so next build no longer inherits an ambient NODE_ENV=development that breaks Next.js 16 prerendering via dual React copies. It is one line, matches the repository's existing inline-NODE_ENV script convention, and all CI checks (Lint, Build, Tests, Typecheck, Docker Build, npm audit) pass on the head commit.

Change-by-Change Findings

package.json (build script): "build": "NODE_ENV=production next build" replaces plain next build. This makes the script match its documented purpose ("Production build") and the already-established NODE_ENV=development prefixes in lint, test, and typecheck. Since next build already defaults to production mode, the change is a no-op for CI and the Dockerfile build path when the ambient env is unset, and only corrects the case where the caller exports NODE_ENV=development.
No other files changed; no dependency, schema, or runtime behavior changes.
PR classification flagged no risk flags and no must_check items, so there are no mandatory checklist entries beyond the diff itself.

Sources

PR PR 768 metadata and diff (1 file changed, +1/-1).
Repository history: head commit 105ae8c; base includes 0aa4c84 (nextjs monorepo 16.3.0 → 16.3.1, PR 767) on origin/main.
CI Check Results for 105ae8c: all checks success.
Repository grep: existing NODE_ENV=development prefixes in package.json scripts; Dockerfile and .github/workflows invoke npm run build.

Standards Compliance

AGENTS.md documents npm run build # Production build; the explicit NODE_ENV=production makes the script conform to that description.
The change follows the repository's existing convention of prefixing scripts with inline NODE_ENV (lint, test, typecheck), so no AGENTS.md Code Standards are violated.
No secrets, database migrations, API routes, or validation paths are touched.

Tool Harness Findings

The tool harness reported only "planning pending" and produced no actionable findings to incorporate into this review.

Unknowns / Needs Verification

CI's Build and Docker Build checks exercise the default env path; the specific NODE_ENV=development npm run build failure/recovery scenarios shown in the PR body were verified locally by the author and are not independently reproduced in CI evidence.
The linked claude.ai analysis session was skipped (host not allowlisted), so that source could not be independently inspected.
The tool harness did not emit concrete findings, leaving the dynamic analysis portion of verification unperformed.

its-saffron · 2026-08-14T12:54:09Z

 "scripts": {
 "dev": "next dev",
- "build": "next build",
+ "build": "NODE_ENV=production next build",


Info: The inline NODE_ENV=production prefix is not portable to Windows cmd/PowerShell, but this matches the repository's existing NODE_ENV=development prefix convention in the lint/test/typecheck scripts.
Automated finding from AI PR review.

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

joryirving closed this Aug 14, 2026

joryirving force-pushed the fix/nextjs-16-prerender-usecontext branch from 1cd352c to 0aa4c84Compare August 14, 2026 12:50

joryirving reopened this Aug 14, 2026

its-saffronBot approved these changes Aug 14, 2026
View reviewed changes

joryirving merged commit c03c0b9 into mainAug 14, 2026
7 checks passed

joryirving deleted the fix/nextjs-16-prerender-usecontext branch August 14, 2026 13:02

its-saffronBot mentioned this pull request Aug 19, 2026
release: 0.5.39 #792
Merged

Uh oh!

Conversation

joryirving commented Aug 14, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

its-saffronBot left a comment

Choose a reason for hiding this comment

AI Automated Review

Recommendation

Change-by-Change Findings

Sources

Standards Compliance

Tool Harness Findings

Unknowns / Needs Verification

Uh oh!

its-saffronBotAug 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

joryirving commented Aug 14, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

its-saffronBot left a comment

Choose a reason for hiding this comment

AI Automated Review

Recommendation

Change-by-Change Findings

Sources

Standards Compliance

Tool Harness Findings

Unknowns / Needs Verification

Uh oh!

its-saffronBotAug 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

joryirving commented Aug 14, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

its-saffronBot left a comment

Choose a reason for hiding this comment

AI Automated Review

Recommendation

Change-by-Change Findings

Sources

Standards Compliance

Tool Harness Findings

Unknowns / Needs Verification

Uh oh!

its-saffronBotAug 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

joryirving commented Aug 14, 2026•
edited
Loading

joryirving commented Aug 14, 2026•
edited
Loading

joryirving commented Aug 14, 2026•
edited
Loading

joryirving commented Aug 14, 2026•
edited
Loading

joryirving commented Aug 14, 2026•
edited
Loading