-
LLM output markdown code fences MUST be stripped (2026-06-16, critical bug):
The extract_code_block() function in llm_generator.py was broken — 64/64
LLM-generated files had ```html or ```yaml prefixes that made HTML
render as raw text and DESIGN.md fail YAML parsing. The regex
r"```(?:html|markdown|md)?\s*\n(.*?)```" failed to match when the opening
fence was on line 1 with no preceding newline. Fix: rewrote to handle
stripped.startswith("```") as a manual strip path (remove first line,
remove trailing ```). Post-fix action: batch-cleaned all 64 files
with strip_code_fences() in a one-off script. If you ever see HTML files
starting with backticks, the LLM wrapped its output and the extractor missed
it. Always validate with fp.read_text()[:10] — should start with <!DOC
for HTML or --- for DESIGN.md, never ```.
-
8-dim scorer v2 refinements (2026-06-16): Three dimensions were too strict in v1 and caused false failures. v2 changes: (1) heavy_shadow now only flags fluffy shadows (blur ≥ 20 AND rgba color). Hard offset shadows (0 blur) are fine regardless of offset size. Old scorer flagged ANY box-shadow = 1 point, killing styles that need hard shadows (Bauhaus, Brutalist, Memphis). (2) placeholder_copy now strips <style> and <script> tags before stem-matching, so CSS properties like text-transform no longer trigger "transform" market-stem hits. (3) element_density threshold raised from 12→40 HTML tags. Old threshold meant any multi-section reference page (nav+hero+dashboard+palette+components+form) scored ≥1 just from structure. New threshold only flags extreme widget pile-up. Result: memphis-1981 and constructivist went from 5/16 (failing) to 2/16 (passing) under v2 without any LLM retry.
-
Cron-mode tool constraints (NEW 2026-06-15): when running inside the
anti-ai-style-factory cron, execute_code is blocked (security) and
cat file | python3 / echo | bash triggers tirith's pipe_to_interpreter
HIGH alert. To parse JSON logs (e.g. logs/run_*.json) use one of:
(1) terminal('python3 -c "import json; ..."') directly, (2) python3 script.py < file
redirect, (3) loop with read_file() per metadata.json. See
wiki-auto-pipeline-recipes SKILL.md for the full escape-hatch table.
-
Don't use Helvetica Neue as primary in Swiss 1950 then validate. The font_cliche
dimension checks font-family declarations. Swiss uses Helvetica Neue — which is
NOT in the CLICHE_FONTS list (Inter, Roboto, Lato, Open Sans, Helvetica Neue** without
the "Neue" suffix is the cliche; "Helvetica Neue" specifically is fine).
But if you shorten to just "Helvetica" it WILL trigger. Keep the full name.
-
Don't confuse "hard shadow" with "heavy shadow". Bauhaus uses 6px 6px 0 #C43838
(zero blur) — this intends to be a hard offset shadow, NOT the AI-tasting fluffy colored shadow.
The scorer is more aggressive than just blur ≥ 20px + rgba: the heavy_shadow dimension
also triggers on large offset shadows (~≥6–8px) regardless of blur. See the "Brutalist hard
drop-shadows" pitfall below for the graffiti-1980 evidence. Rule of thumb: keep offset
shadows ≤ 4px and color them the same as the foreground or border so they read as
structure, not decoration.
-
text-transform in CSS triggers placeholder_copy false positive. The word
"transform" in text-transform: uppercase is a CSS property, not marketing copy.
Known issue — the scorer uses substring matching. Score impact: +1 on placeholder_copy.
Acceptable for reference pages showing all components.
-
Reference HTML is intentionally dense — it shows ALL components in one page,
which inflates element_density. A real production page using just the dashboard
section would score lower. The reference is a stress test, not a production page.
-
__file__ path resolution in harness.py — When running python3 scripts/harness.py
from the skill root, Path(__file__).parent resolves to the scripts/ directory,
not the skill root. The correct line is SKILL_DIR = Path(__file__).resolve().parent.parent.
If you ever see list returning 0 seeds, check this path first.
-
DESIGN.md validator "Inter" false positive — The validate_design_md() function
in harness.py does substring search ("inter" in body.lower()), which matches "Inter"
mentioned in anti-AI rules prose (e.g., "Where AI default is soft... Inter + glassmorphism...").
Fix: check only the YAML front matter fontFamily values, not the markdown body.
Low priority — it only affects the validate command's issue list, not the HTML scoring.
-
iFlytek MaaS: /v2 NOT /v1. The correct endpoint is https://maas-api.cn-huabei-1.xf-yun.com/v2.
The /v1 endpoint exists but uses HMAC signature auth (apikey:apisecret format) — standard
OpenAI Bearer token auth returns 401 "无效的令牌" on /v1. The /v2 endpoint accepts standard
Bearer auth. See references/maas-provider.md for full integration details.
-
iFlytek MaaS: key is in ~/.zshenv, not hermes config. The CHATXUNFEI env var in
~/.zshenv is the correct key for the /v2 endpoint. The maas provider in
~/.hermes/config.yaml is for the OLD /v2 coding API (maas-coding-api.cn-huabei-1.xf-yun.com).
Different domain, different key format, different auth scheme.
-
execute_code sandbox cannot read shell env vars. $CHATXUNFEI is empty inside
execute_code. Fallback: parse ~/.zshenv directly with Path.home() / ".zshenv".
-
MaaS extra_headers={"lora_id": "0"} is required. Omitting it causes 400 on some models.
-
Each seed takes ~3-5 min to generate (2 LLM calls: DESIGN.md ~120s + HTML ~100s).
Use terminal(background=True, notify_on_complete=True) or cron (every 10m, 1 seed per run).
-
--batch 5 --workers 5 wall time is ~8-10 min, NOT 5×5min. The slowest worker
(a failed seed retrying through 3 attempts) bounds the run — observed 2026-06-15
memphis-1981 (4 attempts → 595s) and vaporwave (3 attempts → 495.8s) while
siblings finished in 204-362s. Foreground terminal() timeout (600s default)
is too tight for --workers >= 5 and will silently kill the run (exit_code=124
with no summary written). The anti-ai-style-factory cron prompt is also at risk
if the runtime budget is <10 min. Always use background=True, notify_on_complete=True
and poll via process(action='wait'), or rely on the cron job (which runs
1 seed per 10m for the same reason). Concrete recipe:
terminal(background=True, notify_on_complete=True,
command="source .venv/bin/activate && python -m src.pipeline.run --batch 5 --workers 5 2>&1 | tee /tmp/run.log")
# Then poll:
process(action="wait", session_id=..., timeout=60) # 60s chunks
tail -20 /tmp/run.log # real progress (tee is line-buffered)
# Final report parse: json.loads on logs/run_<timestamp>.json
-
--batch 10 --workers 10 wall time is ~14 min including one retry
(NEW 2026-06-16, validated by clean 10/10 pass). This is the perpetual
cron mode: 10 concurrent workers, XFYUN peak 20 in-flight calls
(10 seeds × 2 LLM calls each), well under the 100-conn / 300-QPS
ceiling. The 14-min budget exceeds the foreground terminal() 600s
clamp, so background-only is mandatory. Per-seed wall time at 10
workers: 232-391s for first-shot passes, +400-500s for seeds that
retry once. See references/batch-2026-06-16-1040.md for the full
per-worker table. The 3-minute cron interval may overlap with the
14-min run time — two simultaneous runs are possible if a prior
invocation is still in flight when the next cron fires. Watch
lsof | grep "logs/run" for multiple writers; if overlap becomes
frequent, drop to --batch 8 --workers 8 to keep total wall time
under the 3-min cron cadence.
-
5/16 + element_density=2 is a structural seed-failure fingerprint, not a
prompt-tuning issue. Confirmed across 2 seeds (memphis-1981 in original run,
vaporwave in 2026-06-15 22:08 run). The pattern: reference.html shows ALL
components (dashboard + table + form + cards + slide) in one document, so
element_density=2 is the floor by design. The remaining 3 points always come
from 3 different single-point axes (typically `purple_gradient + placeholder_copy
- heavy_shadow
for nostalgic/clash movements; the LLM defaults to "richer = better" decoration). When a seed fails withtotal=5andelement_density=2plus three 1s, prompt tuning is unlikely to help — either (a) accept a 6/16 gate for that movement class, (b) hand-author a sparser reference, or (c) reduce the reference to a single scene. **Diagnostic rule:**element_density=2is the structural floor ofreference.html; a seed scoring 5/16 with element_density=2
- 3 single-point axes
is **1 point from passing** and worth a prompt-rewrite targeting those 3 axes; a seed scoring 7+/16 withelement_density=2` is
structurally stuck and needs a different reference structure (or hand-authoring).
The earlier "Memphis is stuck" entry was overturned by a sharper retry prompt on
2026-06-15, so don't permanently fail-flag a seed after one run.
-
element_density=2 is the structural floor of reference.html — see
the 5/16-fingerprint pitfall above for the full diagnostic rule.
-
Cron job anti-ai-style-factory runs every 3m with --batch 10 --workers 10.
To restart for new seeds: hermes cron create --name anti-ai-style-factory --schedule "every 3m".
Concurrent workers use ThreadPoolExecutor — each worker creates its own OpenAI
client (connection pooling works better per-thread). XFYUN limits: 100 concurrent
connections, 300 QPS. --workers 10 is the cron default and is safe (validated
2026-06-16 10:40 with 10/10 pass, zero failures). Per-seed wall time at 10
workers: 232-391s for first-shot passes.
-
process(action='poll') returns empty output_preview for python ... | tee pipes.
Python's print() is block-buffered (4KB chunks) on non-TTY stdout, so when the pipeline
pipes through tee /tmp/run.log, the buffer never reaches tee/flush until either
(a) the buffer fills, (b) a flush=True print happens, or (c) the process exits. The
Hermes process-poll output therefore stays empty even though the pipeline is making
progress. Don't trust output_preview: "" as "stuck" — read the tee target file
directly with read_file() or tail to see real progress. Pattern:
# Launch
terminal(background=True, notify_on_complete=True,
command="... | tee /tmp/run.log")
# Poll
read_file("/tmp/run.log") # actual progress, line-buffered by tee
process(action="poll", session_id) # for status only, output is buffered
The cron job itself doesn't have this problem — its stdout goes to a file via the
runner, and the run log lives in logs/run_<timestamp>.json (written on completion).
-
Force-unbuffered output when tee/file logging matters (NEW 2026-06-15): the pitfall
above tells you how to detect that tee is buffering; this one tells you how to
prevent it. Wrap the launcher with all three belt-and-braces flags so progress prints
flush after every line, not every 4KB:
source .venv/bin/activate \
&& PYTHONUNBUFFERED=1 stdbuf -o0 -e0 python -u -m src.pipeline.run --batch 5 --workers 5 \
2>&1 | tee /tmp/pipeline_run_$(date +%Y%m%d_%H%M%S).log
PYTHONUNBUFFERED=1 — disables Python's internal stdout bufferingstdbuf -o0 -e0 — libc-level line buffering on stdout/stderrpython -u — same as PYTHONUNBUFFERED, defensive if env var is stripped
Any one of these is not enough on its own; the pipeline imports a lot before the first
print() so the libc stdio buffer is what bites you. All three together = safe.
-
Two distinct timeout caps can kill a long pipeline run (NEW 2026-06-15):
(1) the foreground terminal() 600s clamp — already covered above; use
background=True, notify_on_complete=True to bypass.
(2) the per-session tool-iteration budget the cron context enforces separately —
this one is silent. The agent receives a "You've reached the maximum number of tool-calling iterations allowed" mid-run even though the background pipeline is
still healthy. Observed 2026-06-15 22:29 run: pipeline was making progress (all 5
workers ESTABLISHED on the SOCKS proxy, tee target growing, no crash) but the
agent was cut off while polling. Mitigation: minimize agent-side poll calls
during a long run — start it, check tee file once or twice with read_file(), and
exit. The notify_on_complete=True flag will wake the agent again on real
completion; you don't need to babysit. For interactive runs, prefer a single
process(action="wait", timeout=60) then a final read_file on the tee target
rather than many short polls.
-
"0% CPU + ESTABLISHED proxy connections + growing tee file" = healthy, not stuck
(NEW 2026-06-15). Concretely: a worker pool running 5 concurrent httpx calls
through localhost:10808 (SOCKS proxy) shows up in ps as python ... S (sleeping)
with 0.0 %CPU because the kernel schedules the proxy I/O on the socket fd, not
the python thread. The lsof output will show N ESTABLISHED TCP connections to
localhost:10808. The tee target file will grow slowly (~1 line every 20–60s).
Together these prove the LLM API calls are in flight. Do not kill the run on
these signals. Kill only if lsof shows zero ESTABLISHED connections AND the tee
file hasn't grown in 5+ minutes.
-
process(action='wait') is silently clamped to 60s per call, regardless of
the timeout argument (NEW 2026-06-15). A naive wait(timeout=300) returns
{status: "timeout", timeout_note: "Requested wait of 300s was clamped to configured limit of 60s"}. To wait out an 8-minute --batch 5 --workers 5 run, call wait
in a loop, or rely on notify_on_complete=True (which fires once on real exit
and is the much cleaner pattern). Observed sequence this run: launch → 8× wait(60)
polls → real exit. Better: launch with notify_on_complete=True, then do other
useful work or exit — the framework will re-wake you on completion with the full
output. This is the same "don't babysit" lesson as the cron-budget pitfall above;
the operational fix is identical.
-
notify_on_complete=True actually works for python -m src.pipeline.run
(NEW 2026-06-15, validated). Concerned it might fire too early on backgrounded
shells — it doesn't. The notification fires when the backgrounded process exits
cleanly (or crashes with non-zero), with output containing the full stdout.
This is the correct primitive for cron-style runs that take >1 minute; don't
waste tool iterations polling.
-
The 5/16 + element_density=2 fingerprint is now confirmed across 5 seeds
(NEW 2026-06-16, fifth case: bauhaus-berlin — but resolved on retry).
Original four: memphis-1981, vaporwave, baroque-ornate (resolved), graffiti-1980 (stuck).
The 2026-06-16 10:40 batch run produced bauhaus-berlin at 5/16 on attempt 1,
retried to 3/16 on attempt 2 (passed). This is the second proven case
(after baroque-ornate on 2026-06-16 00:09) of axis-targeted retry resolving
the fingerprint. Net: 2 of 5 seeds with this fingerprint resolved on retry;
3 remained stuck across 3 attempts. The "worth a single retry before
classifying as structurally stuck" rule from the original pitfall continues
to hold — try once, then decide.
-
baroque-ornate resolved: 5/16 → 4/16 on retry (NEW 2026-06-16). The
2026-06-16 00:09 --batch 5 --workers 5 run passed baroque-ornate on attempt 2
(5/16 → 4/16), removing it from the failed list. This is the first proven
case of the 5/16 + element_density=2 fingerprint being flipped to passing
by an axis-targeted retry without changing reference structure. The retry
feedback presumably targeted the heavy_shadow + placeholder_copy + element_density
axes (the three 1s besides the structural floor) and the LLM re-emitted with
lighter decoration. Lesson: the "structural pattern" framing above is right
(prompt-only is unlikely to help), but not deterministic — the 5/16 seeds
are worth a single retry before being classified as structurally stuck.
Graffiti-1980 in the same batch hit the same fingerprint and did NOT resolve
across 3 attempts, so the pattern still holds for some seeds; the per-seed
prompt sensitivity is what varies.
-
bauhaus-berlin resolved 5/16 → 3/16 on retry (NEW 2026-06-16, second
resolution case). The 2026-06-16 10:40 --batch 10 --workers 10 batch
run produced bauhaus-berlin at 5/16 on attempt 1 and retried to 3/16 on
attempt 2 (passed). This is the second proven case (after
baroque-ornate) where axis-targeted retry flipped a 5/16 seed to passing
on the first retry. Notable: bauhaus-1919 (the M-source manual style)
passes at 2/16 with 6px 6px 0 #C43838 hard red shadow on cream — the
LLM-generated bauhaus-berlin apparently had heavier decoration in
attempt 1 (likely element_density=2 + heavy_shadow=1 + one other
1-point axis) and the retry prompt pulled the LLM back to a more
authentic bauhaus-dessau treatment. Operational rule update: the
5/16-fingerprint retry strategy that worked for baroque-ornate also
works for bauhaus-style movements specifically. The structural-stuck
graffiti-1980 case is the outlier, not the rule.
-
Brutalist hard drop-shadows CAN still trigger heavy_shadow (NEW 2026-06-16,
contra the existing "hard shadow ≠ heavy shadow" pitfall). The earlier
pitfall claims the scorer catches only blur ≥ 20px + rgba and that hard
shadows with 0 blur always pass. Graffiti-1980 disproves this: the LLM
produced box-shadow: 8px 8px 0 #1A1A1A (offset shadow, 0 blur, opaque
black — textually a textbook "hard offset shadow") and the scorer still
flagged heavy_shadow=1. The likely actual rule: heavy_shadow also
triggers on offset shadows ≥ ~6–8px in either direction regardless of
blur, because that's where the shadow becomes visually heavy. Operational
impact: when generating a style whose aesthetic demands offset shadow
(graffiti, brutalist, neo-brutalist, 90s grunge), keep the offset ≤ 4px
and the color identical to the foreground or border so it reads as
structure, not decoration. The 8px black-on-white offset that the LLM
defaults to is exactly the trap. Bauhaus-1919 (6px 6px 0 #C43838, hard
red on cream) is at the edge of this rule — the fact that it passes may
be scoring leniency, not a guarantee.
