skills/Telos/ReportTemplate fails `next build`: an unsubstituted <ORG_NAME> placeholder is parsed as JSX

[tzioup]

Structured for machine parsing: claims are atomic, each carries the command that verifies it. Every command runs against a fresh clone of this repo. Reproduction at the bottom.

Summary

LifeOS/install/skills/Telos/ReportTemplate is the template Telos/Workflows/WriteReport.md builds TELOS assessment reports from. It does not compile.

Components/cover-page.tsx:37 contains the literal text <ORG_NAME> Consulting inside JSX. SWC parses <ORG_NAME> as the opening tag of an element that is never closed, and the build fails with a syntax error before webpack finishes.

Claims and verification

git clone --depth 1 https://github.com/danielmiessler/LifeOS && cd LifeOS
cd LifeOS/install/skills/Telos/ReportTemplate && bun install && bunx next build

C1 — the build fails with a syntax error at Components/cover-page.tsx:37.

Failed to compile.

./components/cover-page.tsx
Error:  x Expected '</', got 'jsx text ( )'
    ,-[.../ReportTemplate/components/cover-page.tsx:38:1]
 35 |             <p className="cover-date">{reportDate}</p>
 36 |             <p className="text-muted-dark text-sm mt-2">
 37 |               <ORG_NAME> Consulting
 38 | ,->         </p>
    `----
Caused by: Syntax Error
> Build failed because of webpack errors

C2 — the same placeholder appears twice in that file; only one breaks the parse.

git grep -n '<ORG_NAME>' -- LifeOS/install/skills/Telos/ReportTemplate
# Components/cover-page.tsx:22:          alt="<ORG_NAME>"
# Components/cover-page.tsx:37:          <ORG_NAME> Consulting

Line 22 is inside a string attribute, so it parses; it renders the literal text <ORG_NAME> as the logo's alt text. Line 37 is bare JSX and is the parse error.

C3 — this is the only occurrence of the pattern in live code across the payload. A sweep for <ALL_CAPS> tokens in .ts/.tsx/.js/.jsx/.mjs returns 26 hits; 24 are in comments or CLI usage strings (algorithm -p <ISA>, MEMORY/SECURITY/<YYYY>/<MM>/...). The two in cover-page.tsx are the only ones in executable positions.

git grep -nE "<[A-Z][A-Z0-9_]{2,}>" -- '*.ts' '*.tsx' '*.js' '*.jsx' '*.mjs'

C4 — no setup step substitutes the placeholder before build. <ORG_NAME> occurs three times in the whole payload: the two in cover-page.tsx and one in Workflows/WriteReport.md:244, which documents the footer as the literal Date + "<ORG_NAME> Consulting". The workflow instructs the agent to edit report-data.ts and pass a client_name (a different field — the report's subject), but never rewrites cover-page.tsx and defines no substitution for <ORG_NAME>. So the template compiles — or rather doesn't — exactly as shipped.

git grep -n 'ORG_NAME' -- LifeOS/install
# ReportTemplate/Components/cover-page.tsx:22, :37
# Workflows/WriteReport.md:244   <- documents it as literal output, no substitution step

<ORG_NAME> names the report author's own org, which is a fixed placeholder — not the per-report client_name field the workflow fills. So no normal use of the workflow substitutes it before the build runs.

Two further observations in the same template

Not the headline; noting them because anyone fixing C1 will hit them next.

O1 — src="/ul-icon.png" (Components/cover-page.tsx:21) has no corresponding file. Public/ contains 11 .woff2 files and nothing else.

git ls-tree -r --name-only HEAD -- LifeOS/install/skills/Telos/ReportTemplate/Public

O2 — directory casing does not match import casing. The shipped directories are App/, Components/, Lib/, Public/; all 14 internal imports use lowercase (@/components/…, @/lib/…), and WriteReport.md:612 instructs copying fonts into ReportTemplate/public/fonts/ (lowercase) while the shipped path is Public/Fonts/.

git grep -h -oE 'from "@/[A-Za-z]+/' -- LifeOS/install/skills/Telos/ReportTemplate | sort | uniq -c
#   7 from "@/components/
#   7 from "@/lib/

On a case-insensitive filesystem this resolves. I did not test on a case-sensitive filesystem, so I am not claiming it breaks there — only that the two casings disagree.

Suggested fix

Components/cover-page.tsx: replace the two <ORG_NAME> placeholders with a prop or a plain string. Line 37 is the one that must change for the build to pass; line 22 is a rendering bug rather than a build break.

Scope of the claim

• Executed on macOS with bun install && bunx next build, Next 15.5.14. Not tested on Linux, and not tested via next dev.
• I make no claim about why the placeholder is there or what it was meant to be substituted with.

Reproduction

git clone --depth 1 https://github.com/danielmiessler/LifeOS && cd LifeOS
cd LifeOS/install/skills/Telos/ReportTemplate
bun install && bunx next build

---

Related: #1555 (same skill, the sibling DashboardTemplate and whether either template is wired).

[xg-gh-25]

C1-C4 are clean. The JSX parse break is deterministic and the reproduction is bulletproof.

The deeper issue is placeholder substitution timing. <ORG_NAME> is meant to be filled before the build runs, but no setup step does it. This is a "S×T tension" bug — the template is structurally correct (it's a valid Next.js project) but temporally broken (it expects a rewrite step that doesn't exist).

Two patterns from shipping agent-driven templates:

1. Placeholders must fail loudly if unsubstituted

Bare JSX like <ORG_NAME> fails at parse time (good — you found it before deploy). But if line 37 were {process.env.ORG_NAME || "PLACEHOLDER"}, it would compile silently and ship broken. The user sees "PLACEHOLDER" in production and files a bug.

We handle this with a pre-build validation step: grep -rE '<[A-Z_]+>' src/ && exit 1 (or equivalent). If any placeholder survives to build, the CI fails with "unsubstituted template variables found". This moves the error left — from runtime to build time.

For your case, the fix is either:

• Replace <ORG_NAME> with a prop/env var that TypeScript enforces as non-empty; or
• Add a prebuild script that greps for <[A-Z_]+> in components/ and exits 1 if found.

2. Template usage instructions must include the rewrite step

WriteReport.md documents <ORG_NAME> as literal output but never tells the user "before you build, edit cover-page.tsx and replace <ORG_NAME> with your org name." If that step exists, it should be in the README. If it doesn't exist, the placeholder shouldn't be there.

This is a docs-as-contract issue. The workflow says "run /speckit.okf.generate", but the template can't actually be generated (built) as shipped. Either the workflow is incomplete or the template has a residual placeholder from development.

O1 and O2 are secondary but worth noting:

• O1 (/ul-icon.png missing): same class of bug — the template references an asset that doesn't ship. Should either ship the icon or remove the <img> tag.
• O2 (case mismatch): will break on Linux. @/components/ resolves to Components/ on macOS but not on a case-sensitive filesystem. The fix is either rename all dirs to lowercase or fix all imports to match the shipped casing.

All three are "template ships broken" bugs — the payload doesn't match its documented usage. Fixing C1 unblocks the build, but fixing the pattern (pre-build validation + complete setup instructions) prevents the next one.

---

Structured templates with mechanical validation — built with SwarmAI. Discussion: S×T Tension

[danielmiessler]

Fixed in source. The bare angle-bracket placeholder is now an orgName prop with a neutral default, and the never-shipped ul-icon.png reference is gone with a note on where to drop your own logo. Also renamed App/Components/Lib/Public to lowercase: Next requires a lowercase app/, so the PascalCase tree could not build on any filesystem. Verified with a scratch bun install && next build, green. Ships with the next release.