CDE Agent: Project Publisher

Writing portfolio pages by hand for seventy projects takes weeks. The work is fundamentally repetitive — read the repo, summarise the value, render a branded card, push it to the CMS — and yet the gap between a thin auto-generated page and a credible one is enormous. Project Publisher industrialises that pipeline: any project folder turns into a fully analysed, branded, validated portfolio post on a CDE deployment in a single pass.

The problem it solves

A solo architect with seventy active and archived projects who wants each to have a credible portfolio page is looking at forty to sixty hours of focused writing — and the result will still drift in voice and quality between the first project and the seventieth. Tooling that just dumps the README into a CMS produces a thin card that erodes the whole portfolio's credibility on contact.

The standard alternatives are worse. A general-purpose CMS importer publishes whatever JSON you hand it, with no validation, no branded image, and no enforced schema — the operator finds out the engine rejected the payload only when an HTTP 400 lands in the log. A SaaS portfolio builder at thirty to two hundred dollars per seat per month gives you templated pages and templated branding, with no way to bulk-import seventy projects from local folders. A hand-rolled script gets you there for one or two projects but rots the moment the operator adds a new template, a new validation rule, or a new target deployment.

The cost of getting this wrong is real: a portfolio page that reads like filler costs perceived credibility with every CEO, investor, and prospective customer who clicks through. At seventy projects, the difference between "this is a real production engine" and "this is a personal blog" is the entire business positioning.

Who needs this most

• Solo architects with thirty or more shipped projects who want each project to have a credible portfolio page but cannot afford sixty hours of focused writing — the moment this hurts is when a prospective customer asks "where can I see your work?" and the architect has to choose between sending three good pages or seventy thin ones.
• Consultancies and studios running portfolio sites for a roster of products where consistency across pages matters more than per-page polish — the moment this hurts is the week the studio onboards a new partner and has to publish six new project pages by Friday with the same visual and structural quality as the existing thirty.
• Operators of CDE-class CMS deployments who want an inbound-agent pattern they can fork — the moment this hurts is when they realise their content team is hand-copying JSON into the admin panel and getting validation errors back from the engine that could have been caught client-side.

The solution — in plain terms

Project Publisher reads a project folder the way an analyst would. It opens the README, scans the documentation, walks the directory tree, counts the commits, and notices the deployment posture. Then it generates a structured portfolio page — title, hook, value proposition, target audience, distinctive features, current maturity — written in business language a non-engineer can scan in ninety seconds.

The operator drives it from a web UI. Paste a list of folder paths into the Bulk Generate panel, pick a provider (Claude Code by default; Anthropic API or local Ollama as alternatives), and tick "generate featured images" to chain a 1920×1080 branded PNG render after each page. A dashboard shows live status as each project moves from queued through generating to generated — or surfaces a debug dump when the LLM output fails validation.

A three-tier validator catches problems before they reach the publishing endpoint. Hard errors (missing fields, malformed slug, body under two hundred words, placeholder bodies) block the save outright. Soft warnings (SEO fields over the engine's Zod cap) save the file but block publish until fixed via an inline editor. Advisory notes (long body, oversized keypoint values) inform without blocking. The result is a pipeline where the operator never sees an HTTP 400 from the production engine.

Value delivered — what you get

• Cuts portfolio publishing from weeks of manual writing to one afternoon of supervised generation — paste seventy folder paths, hit generate, fix the handful of warnings inline, publish to the live site.
• Catches schema violations before they hit the production engine — the local validator mirrors the CDE's Zod caps, so an seoDescription over one hundred and sixty characters surfaces as a yellow warning badge in the dashboard, not as an HTTP 400 from the publish endpoint.
• Produces a consistent visual identity across every page — every featured PNG renders with the same corner-bracket motif, gradient, eyebrow, title typography, and brand label, so a portfolio of seventy pages reads as one engine, not seventy ad-hoc cards.
• Replaces a stack of SaaS subscriptions — no portfolio builder, no image-as-a-service, no CMS importer. The pipeline runs entirely on the operator's own hardware with bind-mounted state.
• Survives an LLM provider switch without rewriting the pipeline — three providers (Claude Code subprocess, Anthropic Messages API, local Ollama) share one validator, one schema, one image generator. Swapping providers is a config-toml line.
• Same JSON publishes to multiple deployments — one description file can land on rist.sh, ristmind.com, or a local dev CDE; the API key bound to each target picks the persona automatically.
• Idempotent re-runs — the same externalId re-pushes as an update, so iterating on a portfolio page is safe; no duplicate posts ever clutter the live site.

Where it delivers outsized value

Three contexts land best with this tool. Distributed operators with a wide project surface — the architect, consultancy, or studio that has shipped a roster of products and needs to publish them all at consistent quality. The pain is the long tail of "small projects that deserve a real page" that never get one because the per-page cost is too high. Agentic content pipelines — any operator running LLM-driven content production who needs a deterministic post-LLM validation and publishing layer; the provider abstraction and the schema validator generalise to any content type whose LLM output has to clear a Zod-shaped acceptance bar before going live. Self-hosted CMS operators — anyone running a CMS they own rather than a SaaS, who wants an inbound-agent pattern they can fork and adapt; the agent never talks to the CMS database directly, only to the public ingest API, so the same pattern works across any CMS that exposes a scoped publish endpoint.

Distinctive features — why this over the alternatives

• Three-tier validation — separates "block save" (hard errors) from "block publish" (soft warnings) from "inform only" (advisory). The operator can save a draft with warnings, fix them in the dashboard, and only then publish. No generic CMS importer surfaces the engine's Zod constraints before the publish endpoint sees them.
• LLM provider abstraction — the same generation pipeline runs against an agentic Claude Code subprocess (with filesystem exploration via Read/Bash/Grep), a single-shot Anthropic API call, or a local Ollama daemon. The interface is one LLMProvider.generate() method; swapping providers is a config line, not a code change.
• Branded image generator built in — every post ships a 1920×1080 PNG rendered with Pillow: gradient background, corner-bracket frame, eyebrow line for category and status, title, excerpt, brand label, tech-stack summary. No external image service required, no per-render fee.
• Idempotent on externalId — re-publishing the same project updates the existing post instead of creating a duplicate. Operators iterate on a portfolio page freely without polluting the live site.
• Multi-target by construction — four pre-wired targets in the shipped config (local, local_docker, rist_sh, ristmind_com); a single JSON publishes to any of them, with the persona chosen by each target's bound API key rather than by the JSON itself.
• Standalone networking — the agent runs on its own Docker bridge and does not join the CMS's docker network. It starts and works whether or not the local CMS is up; remote targets reach over the public internet via host-gateway routing.

Under the hood — built to last

Python 3.12 with FastAPI for the backend, React 18 and Tailwind for the UI, Pillow for image generation, ReportLab for the per-project PDF sheet. The whole stack ships in one Docker container with all state on bind-mounted host directories — stopping or removing the container loses nothing. The agent never touches the CMS database; the only surface it talks to is the public /api/posts/ingest* endpoint behind a scoped API key. Self-hostable end-to-end, with no SaaS dependency on the critical path.

Current maturity

Project Publisher is in active use. Roughly 7,600 lines of code across Python (agent + FastAPI backend, ~2,200 LOC) and React/JSX (web UI, ~4,000 LOC). Last activity 2026-05-25. Thirteen portfolio JSONs generated under data/descriptions/ for the operator's own portfolio; nine of them already live on rist.sh per the publish journal at data/published.json. This is a working tool used to publish the operator's own portfolio every week — not packaged as an installable product. The current refactor (flat JSON descriptions, three-tier validation, multi-provider abstraction, standalone networking) was finished on 2026-05-22 and has been iterated daily since.

Roadmap — what's next

Two near-term tracks. First, expanding template coverage beyond PORTFOLIO — CHANGELOG for project-update posts, BOOK chapters for long-form companion content to flagship projects. The CDE engine already accepts these templates; the agent's validator and image generator need to learn the new shapes so an operator with seventy projects can also publish the running narrative around them. Second, hardening the operator workflow: per-target preview before publish, batch republish with diffing against the live post, and a richer Cleanup tab that reconciles local descriptions against the publish journal for orphan detection.

A longer-arc direction is converting the inbound-agent pattern itself into a reusable kit. The validator, the schema mirror, the provider abstraction, and the multi-target config are generic enough that a second inbound agent for a different content type — events, podcasts, downloads — would fork most of this codebase. That positions the project as a methodology pattern, not a single-purpose tool.

Working with the architect

Project Publisher is most useful to other operators in three modes. A consultancy or solo architect with a similar publishing problem can commission a custom build modeled on this architecture, tuned to their specific CMS and content shape — the agent pattern works against any CMS that exposes a scoped publish endpoint. A team already running a CDE-class deployment can extend their inbound-agent surface by forking this codebase and adapting the validator, provider, or image generator for a new content type. And any operator building a similar agent pipeline can engage in strategic advisory on agent-based content workflows: schema validation patterns, multi-provider LLM abstractions, idempotent publish design. Reach out via sintegrium.io or LinkedIn for a 30-minute scoping call.

---

Built by Yurii Staryk · Solution Ecosystem Architect