Portfolio CMS

AI technology extraction in the admin panel

• A custom React component (ExtractTechnologiesButton) is mounted into Payload's beforeDocumentControls slot, so extraction is a single click while editing a project
• The button calls a Next.js server action / route handler pair that hands the project's markdown to Claude, then reconciles the result against the Technologies collection — creating missing records with a category from a fixed enum (frontend, backend, database, devops, CMS, language, tool…) and linking them to the project
• Results are validated before writing: URLs, required fields, and category values are checked, and failures are reported back to the editor rather than silently dropped
• On one project this catalogued 23 technologies with no manual data entry

A multi-stage ingest CLI

• pnpm ingest <command> runs a bespoke TypeScript CLI through payload run, so every command has full access to the Payload local API and generated types
• Stages are separate and composable — discover (GitHub scan via the gh CLI plus a URL list), analyze (repo metadata, file tree, stack-revealing config files, plus a live-site probe for title, meta, framework fingerprints and nav links — no clone required), notes, writeup, shots, sheet, publish, remote, status
• The generating stages deliberately produce files, not database rows: everything lands in a gitignored work directory and each project gets an ENTER-ME.md checklist listing every field value, the write-up to paste, and each screenshot's alt text — so the whole thing degrades gracefully to a manual copy-paste workflow if anything upstream fails

Resumable, idempotent pipeline state

• A hand-editable manifest.json is the source of truth; discover only ever appends newly-seen repos and URLs so curated edits survive re-runs
• Each stage records a timestamp plus a SHA-256 fingerprint of its inputs, and skips when the artifact exists and the fingerprint still matches — with a dependency table so changing, say, liveUrl invalidates analysis, screenshots and write-up, while changing display ordering invalidates nothing
• The manifest is fully validated before any command writes: slug format, HTTP(S) URLs, contained screenshot basenames, duplicate detection — malformed input exits nonzero instead of half-writing
• Screenshot capture is transactional: everything is rendered into a temporary sibling directory and only promoted once every target succeeded, every file is a nonempty PNG of the expected dimensions, and exactly one capture is flagged as hero

Structured write-ups split into CMS fields

• writeup prompts Claude twice against the same context briefing — once with the summary instructions to produce the technical description_markdown, once with the case-study instructions to produce structured JSON (summary, client_name, business_challenge, contribution_highlights, outcomes, status) plus an explicit needsReview list for anything the model was unsure about
• publish splits the generated markdown on heading text (loose matching, not position) into intro_markdown, tech_stack_markdown, implementation_markdown and outcome_markdown so the front end can lay each section out independently, while the whole document is retained for extraction
• Unmatched headings and missing sections are reported rather than causing failure — a project that doesn't fit the four-section mould simply publishes with fewer section fields
• Case-study generation failures write a stub sidecar with every field flagged for review, so the write-up stage still succeeds

Authenticated remote publishing

• publish --remote pushes straight to the live instance over its REST API — uploading screenshots, creating or updating the project, and triggering technology extraction — authenticated with an API key from a dedicated third-party-access collection using Payload's useAPIKey auth
• Updates are deliberately partial: omitted fields preserve whatever is already in the CMS, concrete values replace, and an explicit null clears nullable fields, so hand-edits in the admin panel aren't clobbered by a re-publish
• Projects arrive hidden by default unless --visible is passed, so nothing appears on the live site before review
• A companion remote command exposes the same transport for one-off ping/list/get/create/update/delete/upload operations

Migration discipline and reproducible deploys

• A Husky pre-commit hook runs ESLint, Prettier and payload migrate:create, so a schema change can't be committed without its migration
• pnpm build is payload migrate && next build, meaning production migrations are applied as part of the image build rather than as a manual step
• The Docker build uses BuildKit secret mounts for DATABASE_URI and PAYLOAD_SECRET — required for the build-time migration — so credentials never land in image history, and the build fails fast if they're absent
• Deployment is fully automated: GitHub Actions builds and tags the image, pushes to GHCR, then triggers a Dokploy redeploy via its API