Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
This repository is the source of docs.sortie-ai.com.
| Component | Value |
|---|---|
| Static site generator | Hugo ≥ 0.146.0, extended edition |
| Theme | Hextra v0.13.0, pulled as a Hugo Module (see go.mod) |
| Build output | public/ (publishDir in hugo.toml) |
| Hosting | Cloudflare Workers static assets — not Cloudflare Pages |
| Deploy command | npx wrangler deploy — not wrangler pages deploy |
| Deploy config | wrangler.toml, [assets] directory = "./public" |
The site runs on Cloudflare Workers, using the static-assets binding. It was
migrated off Cloudflare Pages in commit 090d160. Several older commit messages
still say "Pages" (for example 5cef252), and comments elsewhere may too. Those
are stale. The authoritative signals, in order:
wrangler.tomlhas[assets] directoryand nopages_build_output_dir. Pages projects have the latter.README.mdstates the stack explicitly and givesnpx wrangler deploy.
Cloudflare's own guidance is to start new projects on Workers rather than Pages; Pages remains supported but receives no new feature investment.
Two representations. Both are live, and neither replaces the other.
-
Static mirrors. Every regular page publishes its Markdown source at
<path>/index.md, and no_index.mdgets one, because[outputs]inhugo.tomlassigns the format topagealone. The format itself is[outputFormats.Markdown], the template islayouts/page.markdown.md. They exist so that an agent can guess a URL rather than having to know about content negotiation. Note the shape:<path>/index.md, never<path>.md, because most content files pin an expliciturl:in front matter and an explicit trailing-slashurloverrides an output format'suglysetting.Every one of these files is served with
X-Robots-Tag: noindex, nofollowby the/*.mdrule instatic/_headers. That header is the only thing keeping the mirrors out of the search index, andstatic/robots.txtmust neverDisallowthem — a Disallow would block the agents they exist for and prevent Google from ever reading thenoindex. -
Content negotiation. Requesting the canonical page URL with
Accept: text/markdownreturns Markdown. That mechanism lives outside this repository — do not look for it inlayouts/orwrangler.toml. It is what the "Copy page" context menu uses; see the comments above[params.page.contextMenu]inhugo.tomlfor the client-side half.
/llms.txt and /llms-full.txt are likewise generated at build time, by the
custom output formats declared at the bottom of hugo.toml. /llms.txt
follows https://llmstxt.org/; /llms-full.txt is a Mintlify convention and
is not in that specification.