feat: comptime evaluation

`comptime` statements/imports and `-` prefixed tags (`<-if>`, `<-for>`,
`<-const>`, `<-log>`, `<-debug>`) evaluate while compiling and leave
only their expanded output. Values reach runtime through a resume-style
AST serializer; primitive reads fold into eagerly escaped static
output. Design doc: comptime.md.

Author: DylanPiercey

.changeset/comptime-evaluation.md

@@ -0,0 +1,6 @@
+---
+"@marko/runtime-tags": minor
+"@marko/compiler": minor
+---
+
+Add compile time evaluation: `comptime` statements/imports and the `<-if>`, `<-for>`, `<-const>`, `<-log>`, and `<-debug>` tags run while compiling and leave only their expanded output. Values reach runtime through a resume-style AST serializer, and primitive reads fold into eagerly escaped static output. `<-define>`, `<-return>`, and userland comptime tags are reserved.

agent-feedback/bugs.md

@@ -41,3 +41,19 @@ therefore relied upon for correctness. A real fix needs `isSupersetSources` to
 use a strict/proper-superset test (equal sources must not prune each other)
 _and_ the corrected arithmetic, then a full snapshot audit — out of scope for a
 one-line change.
+
+## Concise `--` without following whitespace silently swallows one text character
+
+`htmljs-parser@5.12.1 dist/index.mjs (BEGIN_DELIMITED_HTML_BLOCK)` | 2026-07-09 | impact:low | effort:low
+
+Upstream htmljs-parser (exercised via `packages/compiler/src/babel-plugin/parser.js`):
+in concise mode, a text line whose `--` delimiter is not followed by whitespace
+drops the first content character with no error. Verified against the installed
+parser with a bare `createParser({ onText })`: `"--foo"` emits text `"oo"`,
+`"--foo bar"` emits `"oo bar"`, and `"---foo"` emits `"oo"`, while `"-- foo"`
+correctly emits `"foo"`. The delimiter scanner appears to unconditionally skip
+one character after the run of hyphens instead of requiring whitespace. Either
+the missing-whitespace form should be a parse error or the character should be
+kept; silent one-character data loss is the worst of the options. Fix belongs in
+marko-js/htmljs-parser (`BEGIN_DELIMITED_HTML_BLOCK` state) with regression
+tests for `--foo` / `---foo`.

agent-feedback/dx.md

@@ -2,6 +2,12 @@
 
 Friction in builds, tests, tooling, or repo workflows. Format and rules: [README.md](README.md).
 
+## `stripTypes` silently unregisters scriptlet import bindings until the transform-exit crawl
+
+`packages/compiler/src/babel-plugin/index.js:444` | 2026-07-09 | impact:med | effort:low
+
+`stripTypes` temporarily hoists `ImportDeclaration`s out of static scriptlets so the TypeScript transform sees them, then puts them back with a raw `scriptlet.body.unshift(importNode)`. The hoist uses `path.remove()`, which unregisters the import's scope bindings (babel's `_removeFromScope`), and the raw re-insert never re-registers them — so from stripTypes until the crawl at transform **exit**, `scope.getBinding()` misses every import that lives inside a static/comptime scriptlet, while `const` bindings in the same scriptlet still resolve (they never went through the remove/re-add dance). Nothing in the tree looks wrong, which makes this a confusing trap for any pass that classifies identifiers during the transform stage (the comptime pass hit it and now re-crawls defensively at `packages/runtime-tags/src/translator/comptime/index.ts:118`). Fix by re-registering the binding when the import is moved back (e.g. `scriptletPath.scope.getProgramParent().registerDeclaration(...)` via a real path op instead of the raw unshift), then the defensive crawl can go.
+
 ## Fix the broken default translator in `npm run compile`
 
 `scripts/inspect-compiled-output.ts:22` | 2026-07-02 | impact:med | effort:low

agent-feedback/perf.md

@@ -49,3 +49,18 @@ Existing TODO: `<${input.component}/>` style dynamic tags always compile against
 `scripts/test-parallel.js:40` | 2026-07-02 | impact:low | effort:med
 
 `npm run test:parallel` runs one mocha process per core, but each fixture bundle already drives rolldown's own multi-threaded build (`packages/runtime-tags/src/__tests__/utils/bundle.ts`), so even a serial run uses ~1.4 cores. On a 4-core box the whole suite lands at ~87s vs ~238s serial (2.7×), short of the ~4× the core count implies, because the workers contend for the same native threads. `RAYON_NUM_THREADS=1` in the worker env made no measurable difference, so rolldown isn't honoring it. If rolldown (or its native binding) exposes a per-build thread cap, pinning workers to 1 bundler thread each — so N workers ≈ N threads total — could recover much of the lost efficiency and let the runner scale closer to linearly on higher core counts.
+
+## Prune statically-confident `<if>` branches like `<show>` does
+
+`packages/runtime-tags/src/translator/core/if.ts:583` | 2026-07-09 | impact:med | effort:med
+
+`<show>` consults `evaluate()` and, when `.confident`, collapses to plain markup
+(`packages/runtime-tags/src/translator/core/show.ts:80`), but `core/if.ts` never
+calls the evaluator: `<if=false><p>never</p></if><else><p>always</p></else>`
+compiles (optimized html output) to a literal `if (false) {...} else {...}` with
+both branches' `_html` strings, scope ids, and analysis metadata emitted. A
+confident condition could instead select the surviving branch in `getBranches`
+(if.ts:583) before analysis, dropping the dead branch from both output targets.
+Care needed with branch chains (a confident-false head still leaves a live
+`else-if`/`else` chain) and with tag variables/attribute tags inside dropped
+branches.