developer-portfolio: the command that proves production status is missing from its own command table, npm test starts a watcher, and the required URL ships as localhost

The proof of production status is not in the command table

The Status section opens by naming the evidence: `npm run release:check` passes end to end, covering formatting, linting, strict type checking, content validation, unit and component tests, a production build, release validation, link validation, end to end and accessibility tests across three browser engines, and a production dependency audit. That is ten steps, and the chain in `package.json` does contain ten:

"check": "npm run format:check && npm run lint && npm run typecheck && npm run validate:content && npm run test:run && npm run build",
"release:check": "npm run check && npm run validate:release && npm run check:links && npm run test:e2e && npm run audit:prod",

The Commands table underneath lists eight of the eighteen scripts in that file. `release:check`, the command the whole Status section rests on, is not among them. The table also leaves out `start`, `lint`, `format`, `format:check`, `typecheck`, `check:links`, `test:coverage`, and `check:contrast`. So the reader who wants to reproduce the claim the Status section makes is left to assemble the chain from the two lines printed above, and the reader who trusts the table will not find the entry point at all.

CI runs the six-step check, not the ten-step release chain

Pull requests to the `production` branch run three jobs, two of them required: `quality`, covering format, lint, typecheck, content validation, tests and build, and `e2e`, covering all three browser engines plus accessibility. That `quality` list is the six-step `check` and nothing more. Three jobs run and only two are named on the page, so the third job is defined somewhere in the workflow file that the README never describes. Release validation, link validation, and the production dependency audit sit outside `quality`, so a pull request can merge with a broken outbound link, an incomplete content record, or a high severity advisory in runtime dependencies, and no required status check would have caught it. The accessibility gate has its own stated boundary: axe scans fail the run on critical and serious findings, leaving moderate and minor findings to pass. The section describing all this ends mid-word, at the words so renaming one silent, right after explaining that job names are matched by exact string in the branch ruleset.

npm test starts a watcher and test:e2e runs Playwright

Three scripts begin with `test` and none of them overlap:

"test": "vitest",
"test:run": "vitest run",
"test:e2e": "playwright test",

The bare `test` script is the interactive watcher, so the command a developer or a careless script reaches for first never exits on its own. The Commands table documents `test:run` and `test:e2e` and does not mention `test` at all. The `test:e2e` row promises end to end and accessibility tests against a production build, but nothing inside that script builds anything. That guarantee only holds when `test:e2e` runs after `check`, which is how the release chain sequences it. Running it on its own against whatever happens to be in the output directory tests something else. A fourth variant, `test:coverage`, exists and is also absent from the table.

check:contrast runs from scripts/ and is wired into nothing

The `scripts/` directory holds four TypeScript entry points, and `package.json` registers all four as commands: `validate:content` for `scripts/validate-content.ts`, `validate:release` for `scripts/validate-release.ts`, `check:links` for `scripts/check-links.ts`, and `check:contrast` for `scripts/check-contrast.ts`. Three of them appear in `release:check`. The fourth does not appear in `release:check`, does not appear in `check`, is not named in the Commands table, and is not mentioned in the Status section's list of what passes end to end. A contrast checker therefore exists in the repository and runs nowhere in either documented chain or in CI. That matters more than the other omissions here, because the project already treats accessibility as a gate with a stated severity threshold, and contrast is the failure mode axe scanning does not cover.

The variable release validation requires ships as localhost and is called optional

Local setup is three commands, then one optional step:

cp .env.example .env.local

The file that step copies is four comment lines and one assignment:

# Public site URL used for canonical links, Open Graph metadata, and the sitemap.
# Optional during local development; a localhost fallback is applied.
# Release validation requires an absolute HTTPS URL in production.
# This is public metadata, not a secret.
SITE_URL=http://localhost:3000

The same page describes the step as optional environment configuration and says a localhost fallback applies in development. But the file's own third comment states that release validation requires an absolute HTTPS URL in production, so the single variable the release gate depends on is introduced to the reader as optional and handed over pre-set to a value the gate rejects. Follow the copy step literally into a Vercel deployment and canonical links, Open Graph tags, and the sitemap all resolve to localhost.

Unpublished projects have no route, and two 404s must be indistinguishable

The hiding mechanism is build time, not runtime. Zod parses every content record at import, so malformed content fails the build. A selector layer is the only path from content to pages, and it applies one eligibility rule: Published, and classified Public or Sanitized. Project routes are generated at build time from that selector, so an unpublished project has no route, no sitemap entry, and no metadata, and its absence is what hides it rather than a check at request time. The test that guards this is the sharpest one in the suite: an unknown slug and an unpublished slug must return byte-identical responses, on the reasoning that two 404s with different copy would still leak. Every release validation rule is also asserted in both directions, firing against violating content and staying quiet against real content.

Confidentiality has four values and the policy rules two of them out

Three independent axes govern each record. Publication Status answers whether the website shows it, with `draft`, `published`, and `archived`. Delivery Status answers what is really true of the work, with `completed`, `production`, and others. Confidentiality answers whether it is safe to publish at all, with `public`, `sanitized`, `private`, and `restricted`. Only one of those axes has an enforcement rule attached: `production` is rejected unless the record carries a verified `productionConfirmation`. Then the policy says private and restricted material, including raw AI session exports, company documents, internal identifiers, customer or student data, and unsanitized screenshots, never enters this repository at all. Two of the four values in that enum therefore describe records the policy says cannot exist here, which leaves them as schema surface with nothing behind them.

Version 2 is deployed, package.json says 0.1.0, and the default branch is production

Three versioning stories sit side by side. The Status section says version 2 is deployed, indexed, and verified against `docs/release-checklist.md`. `package.json` says `"version": "0.1.0"` and sets `"private": true`, so it was never intended for a registry. The repository has no GitHub releases at all. The default branch is named `production`, which is also the branch Vercel deploys from and the branch pull requests must target, so there is no `main` and no staging branch to merge into first. The dependency versions themselves are exact, with no caret ranges on `next`, `react`, `react-dom`, `react-markdown`, `remark-gfm`, or `zod`, which makes a given build reproducible. What is not versioned is the content itself: a site described as version 2 has no tag, no release, and no entry in the changelog of a repository whose release record is a markdown checklist.

Editorial conclusion

This repository is worth reading as a worked example of build-time hiding: routes are generated from a selector, so an unpublished project has no route, no sitemap entry, and no metadata, and the test suite insists an unknown slug and an unpublished slug return byte-identical responses. Adopt that idea before you adopt the stack. Before you rely on the checks, know that the six-step `check` is what CI enforces, that release validation, link validation, end to end tests, and the production audit run only in the local ten-step chain, and that `check:contrast` is wired into neither. Set `SITE_URL` to an absolute https address yourself, since the example file hands you a localhost value the release gate will reject.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. randifajar/developer-portfolio on GitHub
5. README