An agentic flow for SitecoreAI head apps.

Reads the existing CM's content model — templates, renderings, field contracts — so /architect designs against real shapes, not assumptions. Runs before /architect.

Stands up the decoupled CM + editing host and deploys the baseline — non-interactive, idempotent, from one deploy-admin client. Runs before /implement.

A visual Components Map — every component, its variants, its fields, and a real screenshot — so the Content Author knows when to use which component and which variant. Proven on Umbra Roasters. Runs before authoring.

Writes on-brand copy in a chosen voice and lands it in Sitecore via the Marketer MCP — and commissions on-brand imagery for empty slots. A Content QA gate confirms it actually rendered. The content phase now runs AFTER /ship, against preview.

The final live step. Publishes everything — layout, content, media — onto a LIVE edge context, ser-pulls the authored items back into the CM code base for git durability, and redeploys the public host. Preview-first / publish-last: nothing goes live before this operator-confirmed gate.

4 resolver variants → 2 React shapes

Datasource + Context, each in Item + Children form, look like four distinct patterns. They collapse to TWO React-side payload shapes (single-item flat hash; children-list wrapper). Same React code handles both members of each pair.

Edge has hard, undocumented limits

15-level depth limit kills the standard IntrospectionQuery. Query complexity scales with pagination + nesting — first:100 with nested fields gets rejected, first:10 works. There is no /schema endpoint; POST + per-type introspection is the only path.

Server Action for reads = endless flicker

Server Actions auto-trigger router.refresh() after returning. For mutations, that is the feature. For client-triggered reads from a hover handler, it wipes every NavBranch state, the dropdown closes, the user re-hovers, repeat. Route Handlers have zero refresh side-effect; that is the right tool for reads.

Component-level nav > SXA Navigation Resolver

The resolver was returning fields: [] with no clear cause. Replacing it with a custom GraphQL query — server L1 with hasChildren flag, lazy L2 per-hover — is more predictable, type-safe, recursive to any depth, and stays under Edge limits because each branch fetch is independent.

Support files inside component folders auto-register

Place types.ts, queries.ts, a NavBranch.tsx client child, or an actions.ts under src/components/<X>/ — gen-map registers them as variants of <X> or as standalone Sitecore renderings. Only the rendering .tsx (plus .<Variant>.tsx siblings) belongs in that folder. Everything else lives in src/lib/, src/ui/, or src/app/api/.

Generic parameter names collide silently

Naming a rendering parameter "Levels" made it disappear from the Pages editor — collision with a base-template field. Renaming to "Level" (singular) made it visible. The rule: namespace your rendering-parameter names or use singular forms; avoid Levels / Depth / Style / Items.

A datasource location pin that nothing catches

A rendering whose Datasource Location is a hard GUID rather than a site-relative query silently binds every site that shares it to one site’s content tree. No test, no code review, no build gate and no serialization validation catches it. On a shared CM, fork the rendering rather than mutating it — in-place remediation is a go-live-class decision needing an operator, a baseline and a non-prod rehearsal.

Sibling modules cannot share an include name

Two serialization manifests in the same directory sharing an include name abort the items-as-resources build — and MSBuild reports 0 Errors first, so it reads as a Sitecore-side failure when it is ours. Nine of fifteen include names collided across all six brand modules; they are conventional names, so any CM serializing brands this way hits it the first time it deploys to a new environment. Fix is one folder per module, which moves zero item files.

An empty field can serve a crawler-blocking page at 200

A site whose robots field is never authored does not 404 — it serves a perfectly valid document that says Disallow: /, at a clean 200. Nothing in a build, a test run or a link check has any reason to complain. Measured across the portfolio: five of six shipped sites were excluded from search that way. The robots response is now a named gate at publish — 200 AND no blanket disallow — and the field is seeded at provisioning so it is never empty in the first place.

A fail-open href is a silent dead link

Writing href={link || '/'} looks defensive and is the opposite: a missing link now points at the homepage and returns 200 forever, so no crawler, smoke check or status assertion will ever tell you it is broken. On one build all seven navigation links resolved to / and every one of them passed. A missing destination has to render as no link at all, or fail loudly — never as a plausible one.

Preview and live are two runtimes, and preview is the lenient one

Route-path form, media resolution and cache semantics all differ between the preview and live Edge contexts — and every stage of the build, from local dev to the ship deploy, sits on the permissive side by design. So a whole class of defect is structurally invisible until publish. Worse, a preview-side pass can pin the broken value as the expected one: four links 404-ed for real visitors for days while a route smoke test asserted the wrong URL form and passed. Anything that can differ gets one assertion against the strict surface, manual if necessary.

Ungated reports pushed build history into source files

Code-review and test reports were treated as disposable, so the only clone-surviving home for a hard-won finding was a comment header in the code it concerned. Measured across 1,505 hand-written source files: 28% comment-to-code, 183 files carrying a header essay of 25 lines or more, one component at 227 lines of comment around 22 lines of code — and accelerating, since the two newest builds were the two worst. The root cause was structural rather than stylistic, so the fix was too: those reports are tracked now, and each product keeps a component-grained decision record that a source comment can point at in one line.

Multilingual support

The big one. Author and publish a head app across multiple languages in one run — next-intl wiring, per-language Edge fetches, dictionary loading, and the content agent writing each locale. The playground already carries four languages on file; making the whole flow language-aware is the next major lift.

Earning a fully autonomous run

The capability landed — all five gate tokens can be unticked, and with none of them on the pipeline runs the whole distance unattended, live publish included. What is still open is the trust, not the mechanism: I have not yet let a real brand go from idea to live without looking. That has to be earned run by run, by the self-checks getting good enough that my looking adds nothing.

Testing & hardening

Broader automated coverage across the Sitecore branch — more edge cases, content-resilience, and real-tenant smoke automation — so a green run means more than it does today. The unglamorous work that makes autonomy safe.

Token-consumption optimization

Make each run leaner and cheaper — trim context, prune the dark skills, tighten agent hand-offs, and measure token spend per stage. Efficiency treated as a first-class goal, not an afterthought.

Personalization

Deferred. @sitecore-content-sdk/personalize integration, A/B variants, audience targeting. Distinctively Sitecore; needs its own probing session.

Forms

Deferred. Sitecore Forms rendering, validation, submission flow. A common requirement for any real site; gets its own skill once the first project needs it.