@zvndev/darkmown 0.6.0 → 0.8.0

package/AGENTS.md

@@ -27,6 +27,8 @@ Commands: `darkmown dev`, `darkmown build`, `darkmown serve`.
 
 `{ name }` or `{ name.path }`. Resolves in order: loop item → in-scope value → declared `:state` → otherwise literal text. **Declare state before you bind it** — compilation is line-based, top to bottom, so a `{ x }` or `:if x` must come *after* the `:state x` (or the `:form into x`) that creates it.
 
+The page's frontmatter is in scope as `meta`: `{ meta.title }` prints a field, `{ meta.tags }` joins an array with `, `, and `@loop meta.tags into tag` iterates a frontmatter array (build-time, stays static). Frontmatter arrays are inline only — `tags: [a, b, "x, y"]`; a value without a leading `[` is a plain string.
+
 ## Directives — the complete set (nothing else exists)
 
 ### State and buttons
@@ -41,7 +43,17 @@ Count: { count }
 :button "Add item" -> cart += {"id": 1, "name": "Sticker"}
 :button "Reset" -> count = 0
 ```
-Button actions are a **fixed whitelist**: `x++`, `x--`, `x += <number>`, `list += <json>`, `x = <json>`. Target must be declared `:state`. Values are JSON literals — they cannot reference loop items or other state. **`:button` is for state actions only** — for a link styled as a button, write raw HTML `<a class="btn" href="…">`.
+Button actions are a **fixed whitelist**: `x++`, `x--`, `x += <number>`, `list += <json>`, `x = <json>`. Target must be declared `:state`. Literal values are JSON. **`:button` is for state actions only** — for a link styled as a button, write raw HTML `<a class="btn" href="…">`.
+
+**Per-row actions (inside a reactive `@loop … into item`):** two actions reference the current row instead of a JSON literal —
+```wd
+@loop products into product
+:button "Add to cart" -> cart += product   ← append a COPY of this row to another :state list
+:::
+@loop cart into line
+:button "Remove" -> cart remove line        ← drop this row from the list being looped
+```
+`cart += product` is the only way to carry a loop item into another list (literals still can't reference rows). `<list> remove <item>`: `<list>` must be the loop's own `:state` source and `<item>` the loop variable (both compile-checked). This is the canonical add-to-cart / remove-line / delete-todo pattern — no `.js` needed. Removal targets the exact row, so it is correct even under a `where` filter.
 
 ### Conditionals
 ```wd

package/CHANGELOG.md

@@ -2,6 +2,20 @@
 
 All notable changes to Darkmown are documented here. Versions follow [semver](https://semver.org); pre-1.0 minor versions may contain breaking changes.
 
+## 0.8.0 — 2026-06-14
+
+- **Array frontmatter + readable `meta`.** Frontmatter now parses inline flow arrays — `tags: [sales, revenue, "q1, q2"]` becomes a real array (previously the literal string `"[sales, revenue]"`), with quoted items keeping their internal commas and bracket-free values staying plain scalars. Block sequences (`- item` lines) remain out of scope to keep the parser single-pass.
+- A page's frontmatter is now in scope in its body as `meta`: `{ meta.title }` prints a field, `{ meta.tags }` renders an array joined with `, `, and `@loop meta.tags into tag` iterates a frontmatter array at build time (stays `runtime: false`, zero-JS).
+- A correctness fix in its own right, and the groundwork for reading/emitting bundles in Google Cloud's Open Knowledge Format (markdown + `type`-bearing frontmatter + cross-links). OKF support, if pursued, will be a thin additive export — deliberately not coupled to its v0.1 Draft.
+
+## 0.7.0 — 2026-06-13
+
+- **Per-row actions in reactive loops.** A `:button` inside `@loop … into item` can now act on its own row — the canonical add-to-cart / remove-line / delete-todo pattern, with no hand-written JavaScript:
+  - `cart += item` appends a **copy** of the current row to another `:state` list. This is the only way to carry a loop item into another list (literal action values still can't reference rows); the copy means adding the same source row twice yields two independent lines.
+  - `<list> remove <item>` removes the current row from the list being looped. `<list>` must be that loop's own `:state` source and `<item>` the loop variable — both validated at compile time.
+  The runtime resolves the clicked row by stamping each reconciled node with its item, so removal targets the exact row and stays correct even when the loop is filtered with `where` (index-based removal would not). Closes the last gap blocking a real store demo.
+- Live demo: the reactive page's filtering section is now a full mini-shop — search products, add to cart, remove lines — all composing on one page.
+
 ## 0.6.0 — 2026-06-13
 
 - **State-driven list filtering — `@loop … where <predicate>`.** Filter any loop with conditions that join via `and` / `or`. Operators: `==` `!=` `<` `<=` `>` `>=` and `contains` (case-insensitive substring). Operands are item paths, declared `:state`, numbers, or `"strings"` — a compile-time whitelist (no expressions, no `eval`; `constructor`/`prototype`/`__proto__` rejected in compiler and runtime). **The predicate decides reactivity:** an item-only predicate filters at build time and the page stays zero-JS; a predicate that reads `:state` compiles to a reactive filtered loop driven by the keyed reconciler (rows are baked in for static JSON sources). This replaces the fragile DOM-toggle escape hatch — the #1 gap surfaced by the agent-eval benchmark.

package/README.md

@@ -54,8 +54,24 @@ One syntax everywhere: `{ name }` or `{ name.path }`.
 
 - In-scope static values (include arguments, loop values) resolve at build time.
 - Declared `:state` becomes a live binding.
+- The page's own frontmatter is in scope as `meta` — `{ meta.title }` prints a field.
 - Anything else stays literal text — braces in prose never break a page or pull in the runtime.
 
+## Frontmatter
+
+YAML-style `key: value` frontmatter between `---` fences. Values are strings, plus inline arrays:
+
+```wd
+---
+title: Customers
+tags: [sales, revenue, "q1, q2"]
+---
+```
+
+- `{ meta.title }` prints a scalar; `{ meta.tags }` prints an array joined with `, `.
+- `@loop meta.tags into tag` iterates an array field at build time (stays static, zero-JS).
+- Arrays are inline flow only (`[a, b]`); quoted items keep internal commas (`"q1, q2"`). A value without a leading `[` stays a plain string.
+
 ## Loops
 
 `@loop <things> into <thing>` is the only loop. The source decides the behavior:
@@ -101,6 +117,34 @@ Operators: `==` `!=` `<` `<=` `>` `>=`, plus `contains` for case-insensitive sub
 
 `:bind <state>` renders an `<input>` wired two-way to a `:state` value — typing updates the state, and the state reflects back into the field. It accepts `type=` (default `text`), `placeholder=`, `autocomplete=`, and the `required` / `autofocus` flags.
 
+### Editable lists — per-row actions
+
+A `:button` inside a reactive `@loop` can act on its own row. Two row actions exist:
+
+```wd
+:state products = [{"id": 1, "name": "Aurora", "price": 49}]
+:state cart = []
+
+@loop products into product
+::: card
+**{ product.name }** — ${ product.price }
+:button "Add to cart" -> cart += product    <- carry this row into another list
+:::
+@endloop
+
+@loop cart into line
+::: card
+{ line.name }
+:button "Remove" -> cart remove line          <- drop this row from the looped list
+:::
+@endloop
+```
+
+- `cart += <item>` appends a **copy** of the current row to another `:state` list, so adding the same product twice gives two independent lines.
+- `<list> remove <item>` removes the current row from the list being looped. The `<list>` must be that loop's own `:state` source and `<item>` must be the loop variable — both checked at compile time. Removal targets the exact row, so it stays correct even when the loop is filtered with `where`.
+
+That is a full add-to-cart / remove-line flow — and a to-do list with delete — in plain Markdown, no JavaScript.
+
 ## Sections
 
 ```wd

package/docs/okf-integration.md

@@ -0,0 +1,120 @@
+# OKF integration — plan & options
+
+Status: **parked / decision pending** (2026-06-14). Research-verified; revisit when
+we decide how far to take it. v0.8.0 (array frontmatter + readable `meta`) already
+shipped the enabling groundwork.
+
+## What OKF is (verified)
+
+**Open Knowledge Format (OKF)** is real. Published **2026-06-12** by the Google Cloud
+Data Analytics team (Sam McVeety, Amir Hormati).
+
+- Announcement: <https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/>
+- Spec: <https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md>
+- Repo (Apache-2.0, `okf/` subdir): <https://github.com/GoogleCloudPlatform/knowledge-catalog>
+- **Not** the Open Knowledge Foundation (unrelated nonprofit — do not conflate).
+
+It is a **file format**, not a service: a directory of markdown "concept" files for
+feeding organizational knowledge to AI agents. Each concept file has YAML frontmatter
+where **`type` is the only required field**; `title`, `description`, `resource` (a URI
+for the underlying asset), `tags` (a YAML list), and `timestamp` (ISO 8601) are
+optional. Producers may add arbitrary keys; consumers must preserve unknown keys.
+
+- **Cross-links** are ordinary markdown links between concept files (bundle-relative
+  absolute like `/tables/customers.md` recommended). They are treated as **directed,
+  untyped graph edges** — the relationship's meaning lives in surrounding prose.
+- **Reserved files:** `index.md` (a directory listing for *progressive disclosure* — an
+  agent navigates one level at a time) and `log.md` (chronological history). The root
+  `index.md` frontmatter may declare `okf_version: "0.1"`.
+- **Conformance is permissive:** consumers MUST tolerate broken links, unknown `type`
+  values, unknown keys, and missing optional fields (so agent-generated, partial bundles
+  still work).
+- **Reference tooling (both labeled proof-of-concept):** a BigQuery *enrichment agent*
+  that drafts OKF docs per table, and a *visualizer* — a `visualize` command that emits a
+  single self-contained interactive HTML file (Cytoscape.js force-graph + marked.js body,
+  no backend).
+- **Sample bundles:** GA4 e-commerce, Stack Overflow, Bitcoin. ("BigQuery Table /
+  Dataset / Metric" are concept *types inside* bundles, not separate samples.)
+
+## Why it's interesting for Darkmown
+
+OKF's entire surface — YAML frontmatter + a folder tree + relative markdown links →
+static HTML — **is what Darkmown already does**. A `.md` tree with a `type:` field and
+cross-links is *nearly an OKF bundle by accident*. Two directions:
+
+1. **Darkmown as an OKF renderer.** Darkmown renders markdown bundles to static, zero-JS
+   HTML — directly competitive with OKF's reference visualizer, which is OKF's weakest
+   surface (a single JS-heavy HTML file).
+2. **Every Darkmown site emits an OKF bundle.** Any docs/content site also becomes
+   machine-readable agent context. No other markdown framework offers this.
+
+## Why to be cautious
+
+- **v0.1 "Draft," explicitly evolving.** Google's own blog: "a starting point, not a
+  finished standard." Field names and required fields may change (minor versions promise
+  backward-compatible additions only; breaking changes need a major bump).
+- **Thin traction.** ~1.2k GitHub stars but ~8 issues, ~13 PRs, ~27 commits at launch.
+  **No third-party adopters** — only Google's own Cloud Knowledge Catalog consumes it.
+- **Governance unclear.** Lives under Google's repo with no foundation/working group.
+- **Thin convention.** Net-new over "a markdown vault + Obsidian/Dataview" is small: one
+  required field, two reserved filenames, link-as-edge semantics. Easy for others to
+  ignore or fork.
+
+## Decision (Kirby, 2026-06-14)
+
+**Support OKF naturally; do not tie ourselves to it.** Treat it as a cheap, additive
+interop convention, not a strategic bet or a core-model change.
+
+## Options (revisit later)
+
+### Option A — Do nothing more (status quo)
+v0.8.0 array frontmatter already makes Darkmown frontmatter able to carry `tags` lists
+and a `type` field. A Darkmown content tree with `type:` in frontmatter is already
+~conformant. Cost: zero. Keep tracking adoption.
+
+### Option B — Thin OKF emit (recommended first step if we act) — increment #3
+A flag-gated export from a built site: `okf: true` in config or `--emit-okf`.
+- During `buildSite` (`src/builder.js`), alongside `routes.json`, write `dist/okf/`.
+- For each page, emit an OKF doc: frontmatter (`type` defaulting to `page`, `title` from
+  meta, `tags` from meta, `timestamp` from file mtime/git) + the page's markdown body.
+- Derive edges from internal links + `@include` edges (`resolveInclude`/`compileFile`
+  already know these). Emit per-directory `index.md` for progressive disclosure.
+- **Map at emit time** — do not restructure Darkmown's internal model around OKF.
+- Effort: low; it hooks the existing route loop. Largely free.
+
+### Option C — OKF render mode ("best OKF renderer") — increment #2
+`darkmown build --okf ./bundle [--out dist-okf]`: walk an arbitrary bundle root, render
+each doc (type-aware templates, generic fallback), rewrite `.md` cross-links to routes,
+emit a static index/graph view. Reuse `parseFrontmatter`, markdown-it, `compileFile` —
+do not fork the pipeline. Must stay `runtime: false`.
+- **Gate this on OKF showing real external adoption.** Today you'd build a renderer for a
+  format only Google uses. Higher effort, higher coupling risk.
+
+### Sequencing if we proceed
+1. (done) Array frontmatter + readable `meta` — v0.8.0.
+2. Option B (emit) — additive, low-regret.
+3. Option C (render) — only if the format gets stickier.
+
+## Hard "avoid" list
+
+- Don't hardcode Google/BigQuery `type` vocabularies (`BigQuery Table`, etc.) — `type` is
+  uncentralized and producer-defined.
+- Don't bet on v0.1 field names / required-field stability — map our frontmatter → OKF at
+  emit time.
+- Don't depend on OKF's reference enrichment agent or visualizer — both are proofs of
+  concept. If we want a graph view, build our own; the format is trivial.
+- Don't market "OKF-native" as a moat — it's a thin convention with thin adoption. A
+  cheap interoperability checkbox, not a strategic bet.
+
+## Invariants to respect (if/when we build)
+
+- `.md` never gains directive behavior; OKF docs are content, rendered as content.
+- No eval of bundle content; the `constructor`/`prototype`/`__proto__` rejection in
+  `getPath` still applies.
+- OKF render/emit are pure content transforms — `runtime: false` always.
+- Compile/render errors include the offending file path and a corrective suggestion.
+
+## Source
+
+Full research briefing (cited): the research-investigator memory
+`reference_okf_open_knowledge_format.md`, and `docs/spec-alignment.md` Stage 7.

package/docs/spec-alignment.md

@@ -51,10 +51,15 @@ This audit compares the current Darkmown implementation with the original MARROW
 - **Nested `:if` over loop items (v0.5.0):** conditionals nest inside reactive `@loop`, per row. Both fill paths fixed — build-time balanced `matchElement` recursion and runtime `fillItem` recursion.
 - **State-driven list filtering — `@loop … where <predicate>`:** the #1 need surfaced by the agent-eval benchmark. Conditions (`field <op> value`, plus `contains`) join with `and` / `or` over a compile-time-validated whitelist — item paths, declared `:state`, numbers, strings; `constructor`/`prototype`/`__proto__` rejected, no `eval`. The source decides reactivity, matching the loop itself: an item-only predicate filters at build time and stays zero-JS; a predicate that reads `:state` compiles to a reactive filtered loop (rows baked in for static sources). This replaces the fragile DOM-toggle escape hatch with the keyed reconciler.
 - **`:bind <state>`:** two-way `<input>` bound to a `:state` value — the input primitive that powers live search. Accepts `type=`, `placeholder=`, `autocomplete=`, `required`, `autofocus`.
+- **Per-row actions in reactive loops:** a `:button` inside `@loop … into item` can act on its own row — `cart += item` appends a copy of the row to another `:state` list (the only way to carry a loop item into another list), and `list remove item` removes the row from the looped `:state` source (both names compile-checked against the enclosing loop). The runtime resolves the clicked row by stamping each reconciled node with its item, so removal is exact even under a `where` filter. This closes the last "store demo" gap noted in the design memory (per-row `:button` couldn't carry row data); `:if` string-equality remains the only listed gap, now partly covered by `@loop … where`.
 - **`.skin` robustness:** `@media`/`@supports` at-rules wrap nested rules; the `font` shorthand passes through (size-led or containing `/`) while `font <stack>` still aliases to `font-family`; `/* … */` block comments and decorative divider lines are skipped.
 - **Editor tooling:** VS Code extension (`editors/vscode`) ships `.wd` + `.skin` TextMate grammars, snippets, and folding, grammar-tested in CI.
 - **`AGENTS.md`:** a model-facing build guide (shipped in the npm files array), tuned over a 5-round agent-eval benchmark that lifted build quality from 2.78→4.51/5.
 
+## Stage 7 additions (2026-06-14)
+
+- **Array frontmatter + readable `meta`:** `parseFrontmatter` now parses inline flow arrays (`tags: [a, b, "x, y"]` → real array; quoted items keep internal commas; a value without a leading `[` stays a scalar — block sequences are intentionally out of scope to keep the parser single-pass). A page's frontmatter is exposed to its body under `meta`, so `{ meta.title }` prints a field, `{ meta.tags }` renders an array joined with `, `, and `@loop meta.tags into tag` iterates a frontmatter array at build time (stays `runtime: false`). Genuine correctness fix on its own, and the groundwork for reading/emitting OKF-style bundles (Google Cloud's Open Knowledge Format — markdown + `type`-bearing frontmatter + cross-links; tracked but deliberately not coupled to its v0.1 Draft).
+
 ## Still missing from the full vision
 
 - First-party server runtime (`site/api/`), HTML-fragment `swap` semantics, and cart server sync — parked behind the adapter decision until a real project needs them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zvndev/darkmown",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "private": false,
   "publishConfig": {
     "access": "public"

package/site/pages/docs/index.wd

@@ -88,14 +88,43 @@ The predicate decides reactivity exactly like the source does: read only the row
 
 `:bind <state>` renders an `<input>` wired two-way to a `:state` value — type and the list filters as you go.
 
+### Editable lists with per-row actions
+
+A `:button` inside a reactive loop can act on its own row — the basis for carts and to-do lists:
+
+```wd
+@loop products into product
+:button "Add to cart" -> cart += product
+:::
+@loop cart into line
+:button "Remove" -> cart remove line
+:::
+```
+
+`cart += product` appends a copy of the current row to another `:state` list; `cart remove line` removes the current row from the list being looped. Both are checked against the enclosing loop at compile time — no JavaScript.
+
 ## Interpolation
 
 One syntax everywhere: `{ name }` or `{ name.path }`.
 
 - If the name is a static value in scope (include argument, loop value), it is resolved at build time.
 - If the name is declared `:state`, it becomes a live binding.
+- The page's frontmatter is in scope as `meta` — `{ meta.title }` prints a field.
 - Otherwise the text is left exactly as written — braces in prose never break a page or pull in the runtime.
 
+## Frontmatter
+
+Frontmatter sits between `---` fences. Values are strings, plus inline arrays:
+
+```wd
+---
+title: Customers
+tags: [sales, revenue, "q1, q2"]
+---
+```
+
+`{ meta.title }` prints a scalar and `{ meta.tags }` joins an array with `, `. You can loop a frontmatter array at build time — `@loop meta.tags into tag` — and the page stays static. Arrays are inline flow only (`[a, b]`); quoted items keep their commas.
+
 ## Sections
 
 `::: section #id .class` opens a container and `:::` closes it. Sections scope state: a `:state` declared inside a section belongs to that section, so two sections can both declare `count` without colliding. Bindings and buttons resolve to the nearest scope.

package/site/pages/reactive.skin

@@ -60,3 +60,33 @@ ul
 
 .tally-card h3
   color $warm
+
+.card.product
+  display flex
+  align-items center
+  justify-content space-between
+  gap 1rem
+  border 1px solid $line
+  bg $panel
+  padding .6rem 1rem
+  margin .5rem 0
+  radius $radius
+
+.card.product p
+  margin 0
+
+.card.line
+  display flex
+  align-items center
+  justify-content space-between
+  gap 1rem
+  border 1px solid $line
+  padding .5rem 1rem
+  margin .4rem 0
+  radius $radius
+
+.card.line button
+  bg transparent
+  color $warm
+  border 1px solid $line
+  padding .35rem .8rem

package/site/pages/reactive.wd

@@ -69,16 +69,31 @@ Each row picks one of three states from two nested conditionals, all in plain Ma
 `@loop … where` filters a list, and because the predicate reads a `:state` value, the loop re-filters live as you type. `:bind` is the input bound two-way to that state. Type below and watch the list narrow — no event handlers, no JavaScript:
 
 :state products = [{"id": 1, "name": "Aurora Lamp", "price": 49}, {"id": 2, "name": "Briza Fan", "price": 39}, {"id": 3, "name": "Cove Speaker", "price": 89}, {"id": 4, "name": "Dune Mug", "price": 12}, {"id": 5, "name": "Ember Kettle", "price": 64}]
+:state cart = []
 :state q = ""
 
 :bind q placeholder="Search products…"
 
 @loop products into p where p.name contains q
-- **{ p.name }** — ${ p.price }
+::: card .product
+**{ p.name }** — ${ p.price }
+:button "Add to cart" -> cart += p
+:::
 @endloop
 
 The predicate whitelist is compile-time validated — item fields, declared state, numbers, and strings only. An item-only predicate (say `where p.price < 50`) would instead filter at build time and ship zero JavaScript.
 
+### …and an editable cart
+
+A `:button` inside a loop can act on its own row. **Add to cart** carries the row into another list; **Remove** drops a line — a whole add/remove flow with no JavaScript:
+
+@loop cart into line
+::: card .line
+{ line.name } — ${ line.price }
+:button "Remove" -> cart remove line
+:::
+@endloop
+
 ## Section-scoped state
 
 Two sections can each own a state value named `tally` without colliding. Buttons resolve to the nearest scope:

package/src/compiler.js

@@ -82,7 +82,9 @@ function compileFile(file, context, stack, scope, comp, sections, loopItem) {
     return { meta, html: md.render(body, {}) };
   }
 
-  const ctx = { file, context, stack: [...stack, real], scope, comp, sections, loopItem };
+  // Expose this file's frontmatter to the body under `meta` so `{ meta.title }`,
+  // `{ meta.tags }`, and `@loop meta.tags into tag` resolve as static values.
+  const ctx = { file, context, stack: [...stack, real], scope: createScope(scope, { meta }), comp, sections, loopItem };
   return { meta, html: compileBody(body.replace(/\r\n?/g, "\n").split("\n"), ctx) };
 }
 
@@ -95,11 +97,49 @@ export function parseFrontmatter(raw) {
   const meta = {};
   for (const line of front.split("\n")) {
     const match = line.match(/^([A-Za-z0-9_-]+):\s*(.*)$/);
-    if (match) meta[match[1]] = stripQuotes(match[2]);
+    if (match) meta[match[1]] = parseFrontmatterValue(match[2]);
   }
   return { meta, body };
 }
 
+// Frontmatter values are scalars, except an inline flow array `[a, b, c]`.
+// Block sequences (`- item` on following lines) are intentionally out of scope —
+// the parser stays single-pass and line-based.
+function parseFrontmatterValue(raw) {
+  const value = raw.trim();
+  if (value.startsWith("[") && value.endsWith("]")) return parseInlineArray(value);
+  return stripQuotes(value);
+}
+
+function parseInlineArray(raw) {
+  const inner = raw.slice(1, -1);
+  if (inner.trim() === "") return [];
+  const items = [];
+  let buf = "";
+  let quote = null;
+  let quoted = false;
+  const push = () => {
+    items.push(quoted ? buf : buf.trim());
+    buf = "";
+    quoted = false;
+  };
+  for (const char of inner) {
+    if (quote) {
+      if (char === quote) quote = null;
+      else buf += char;
+    } else if ((char === '"' || char === "'") && buf.trim() === "") {
+      quote = char;
+      quoted = true;
+    } else if (char === ",") {
+      push();
+    } else {
+      buf += char;
+    }
+  }
+  push();
+  return items;
+}
+
 // ---------------------------------------------------------------------------
 // Block parser: directives + prose segments
 // ---------------------------------------------------------------------------
@@ -705,7 +745,7 @@ function staticUnroll(rows, itemName, bodyLines, ctx) {
 
 function reactiveLoop(key, itemName, bodyLines, ctx, opts = null) {
   ctx.comp.assets.runtime = true;
-  const templateCtx = { ...ctx, loopItem: itemName, scope: createScope(ctx.scope) };
+  const templateCtx = { ...ctx, loopItem: itemName, loopKey: key, scope: createScope(ctx.scope) };
   const templateHtml = compileBody(bodyLines, templateCtx).trim();
 
   let wrapperTag = "div";
@@ -868,7 +908,9 @@ function resolveBindingHtml(expr, ctx) {
 
   const staticValue = lookupVar(ctx.scope, head);
   if (staticValue.found) {
-    return escapeHtml(getPath(staticValue.value, segs.slice(1)) ?? "");
+    const resolved = getPath(staticValue.value, segs.slice(1));
+    if (Array.isArray(resolved)) return escapeHtml(resolved.join(", "));
+    return escapeHtml(resolved ?? "");
   }
 
   const key = resolveStateKey(head, ctx);
@@ -933,17 +975,41 @@ function parseAction(raw, ctx) {
   if (increment) return { op: "inc", target: resolveTarget(increment[1]) };
   const decrement = expression.match(/^([A-Za-z_$][\w$]*)--$/);
   if (decrement) return { op: "dec", target: resolveTarget(decrement[1]) };
+  // Per-row: carry the current loop item into another list — `cart += product`.
+  // Only inside a reactive @loop; the runtime resolves the row from the DOM.
   const add = expression.match(/^([A-Za-z_$][\w$]*)\s*\+=\s*(.+)$/);
   if (add) {
+    const rhs = add[2].trim();
+    if (ctx.loopItem && rhs === ctx.loopItem) {
+      const target = resolveTarget(add[1]);
+      if (!Array.isArray(ctx.comp.state.get(target))) {
+        throw new Error(`Button action "${raw}" needs ${add[1]} to be a :state list (declare it "${add[1]} = []") in ${ctx.file}.`);
+      }
+      return { op: "append-row", target };
+    }
     const target = resolveTarget(add[1]);
-    const value = parseActionLiteral(add[2]);
+    const value = parseActionLiteral(rhs);
     if (Array.isArray(ctx.comp.state.get(target))) return { op: "append", target, value };
     if (typeof value === "number") return { op: "add", target, value };
     throw new Error(`Unsupported button action "${raw}". += with non-number values requires a list state target.`);
   }
+  // Per-row: remove the current row from the list being looped — `todos remove todo`.
+  const remove = expression.match(/^([A-Za-z_$][\w$]*)\s+remove\s+([A-Za-z_$][\w$]*)$/);
+  if (remove) {
+    if (!ctx.loopItem) {
+      throw new Error(`Button action "${raw}" is only valid inside a reactive @loop in ${ctx.file}. Use: :button "Remove" -> list remove item`);
+    }
+    if (remove[2] !== ctx.loopItem) {
+      throw new Error(`Button action "${raw}" must remove the loop item "${ctx.loopItem}" in ${ctx.file}, not "${remove[2]}".`);
+    }
+    if (!ctx.loopKey || resolveStateKey(remove[1], ctx) !== ctx.loopKey) {
+      throw new Error(`Button action "${raw}" must target the :state list being looped (@loop ${remove[1]} into ${ctx.loopItem}) in ${ctx.file}.`);
+    }
+    return { op: "remove", target: ctx.loopKey };
+  }
   const assign = expression.match(/^([A-Za-z_$][\w$]*)\s*=\s*(.+)$/);
   if (assign) return { op: "set", target: resolveTarget(assign[1]), value: parseActionLiteral(assign[2]) };
-  throw new Error(`Unsupported button action "${raw}". Supported actions: count++, count--, count += 1, items += "value", name = "value".`);
+  throw new Error(`Unsupported button action "${raw}". Supported actions: count++, count--, count += 1, items += "value", name = "value", list remove item (in a loop), cart += item (in a loop).`);
 }
 
 function parseActionLiteral(raw) {

package/src/runtime.js

@@ -132,6 +132,7 @@ function render() {
       }
       used.add(key);
       fillItem(node, item);
+      node.__wdItem = item; // let per-row actions resolve which row was clicked
       out.appendChild(node);
     }
     for (const [key, node] of existing) {
@@ -156,6 +157,14 @@ document.addEventListener("input", (event) => {
   render();
 });
 
+// The clicked button's row: the nearest reconciled loop node carries its item.
+function clickedRow(el) {
+  const row = el.closest("[data-wd-loop-key]");
+  const region = el.closest("[data-wd-loop]");
+  if (!row || !region) return null;
+  return { srcKey: region.getAttribute("data-wd-loop"), item: row.__wdItem };
+}
+
 document.addEventListener("click", (event) => {
   const action = event.target.closest("[data-wd-action]");
   if (!action) return;
@@ -169,6 +178,20 @@ document.addEventListener("click", (event) => {
   if (op === "add") state[target] = Number(state[target] ?? 0) + Number(value);
   if (op === "append") state[target] = [...(Array.isArray(state[target]) ? state[target] : []), value];
   if (op === "set") state[target] = value;
+  if (op === "remove") {
+    const row = clickedRow(action);
+    if (row && row.srcKey) state[row.srcKey] = (Array.isArray(state[row.srcKey]) ? state[row.srcKey] : []).filter((x) => x !== row.item);
+  }
+  if (op === "append-row") {
+    const row = clickedRow(action);
+    // Clone the row so each appended line is a distinct object — otherwise adding
+    // the same source row twice yields two identical references and a later
+    // remove (filter by !== ref) would delete both lines.
+    if (row && row.item !== undefined) {
+      const copy = row.item && typeof row.item === "object" ? structuredClone(row.item) : row.item;
+      state[target] = [...(Array.isArray(state[target]) ? state[target] : []), copy];
+    }
+  }
   savePersisted();
   render();
 });