Proof A — Ecco-style per-item columns and multiple views, in the vault

Throwaway proof for ecco-replacement-research. Outside any /Tasks/ path so Core/DASHBOARD.md’s Bases block does not pick it up. Delete or archive once the checks are done.

Round 1 result (confirmed on screen 2026-08-20): Views 1–3 returned 7 / 3 / 1 rows with all five columns populated. One cosmetic defect — the Item column repeated every field after the text.

Round 2 adds: the cosmetic fix, and the thing that actually matters — depth. The outline below is now four levels deep, because real project work is.

The outline — four levels, fields on items at every level

• Chilton partnership [abc:: A] [status:: WIP] [action:: manage] [focus:: today]
  • Draft the follow-up email [abc:: A] [status:: WIP] [action:: call] [focus:: today]
    • Confirm the send date with Talbot [abc:: A] [status:: waiting] [action:: ask] [focus:: today]
      • Check his Friday calendar block [abc:: B] [status:: todo] [action:: do] [focus:: thisWeek]
    • Attach deck v2 [abc:: B] [status:: todo] [action:: do] [focus:: thisWeek]
  • Agree the revenue split [abc:: A] [status:: todo] [action:: decide] [focus:: thisWeek]
• Rate scanner — daily ops check [abc:: A] [status:: recurring] [action:: do] [focus:: today]
• Refresh Filter+Focus (4.5 months stale) [abc:: B] [status:: todo] [action:: decide] [focus:: thisWeek]
• Decide Ecco replacement path [abc:: B] [status:: WIP] [action:: decide] [focus:: thisWeek]
• Buy new label printer [abc:: C] [status:: todo] [action:: buy] [focus:: someday]

View 1 — “All items, by ABC”, text cleaned (Ecco: the master notepad)

regexreplace strips the inline fields out of the text cell — that is the fix for the duplication seen in round 1.

TABLE WITHOUT ID regexreplace(item.text, "\s*\[\w+::[^\]]*\]", "") AS "Item", item.abc AS "ABC", item.status AS "Status", item.action AS "Action", item.focus AS "Focus"
FROM "Core/Processes/Projects/Focus/proofs/ecco-columns-proof"
FLATTEN file.lists AS item
WHERE item.abc
SORT item.abc ASC

View 2 — “Today only”, with a Parent column (the depth question)

A flat filtered table loses ancestry. This asks Dataview to put the parent back as a column.

TABLE WITHOUT ID regexreplace(item.text, "\s*\[\w+::[^\]]*\]", "") AS "Item", item.abc AS "ABC", item.status AS "Status", regexreplace(nonnull(map(filter(file.lists, (p) => p.line = item.parent), (p) => p.text))[0], "\s*\[\w+::[^\]]*\]", "") AS "Parent"
FROM "Core/Processes/Projects/Focus/proofs/ecco-columns-proof"
FLATTEN file.lists AS item
WHERE item.focus = "today"
SORT item.abc ASC

If the Parent column errors or comes back blank, say so — that is the honest limit of the flat-table approach, and it decides whether View 3 below is the answer instead.

View 3 — the depth test: does a filtered view keep the tree?

Same items, rendered as a Dataview list rather than a table. The question is whether the four-level structure survives filtering, or whether every view is unavoidably flat.

LIST WITHOUT ID regexreplace(item.text, "\s*\[\w+::[^\]]*\]", "")
FROM "Core/Processes/Projects/Focus/proofs/ecco-columns-proof"
FLATTEN file.lists AS item
WHERE item.focus = "today"

What to look for: is “Confirm the send date with Talbot” shown nested under “Draft the follow-up email” under “Chilton partnership”, or are all three flush left as siblings? This is the single most important thing this proof now tests.

Round 3: View 3 came back flat, so the depth test continues in a separate file — ecco-tasks-depth-proof.md — using checkbox items instead of plain bullets. Views 1–3 below are now scoped to this file only, so its items cannot contaminate these counts.

Contrast — the same question asked of Bases

filters:
  and:
    - file.path.contains("Focus/proofs")
    - file.name.contains("columns")
views:
  - type: table
    name: Bases sees files, not items
    order:
      - file.name

Expected: exactly one row — this note. Bases cannot reach the ten bullets above. (Round 1 confirmed the sibling proof: when each item is a file, Bases works and its cells are editable.)

Expected rows (computed mechanically)

• View 1: 10 rows — every bullet, sorted A A A A A, B B B B, C.
• View 2: 4 rows — Chilton partnership · Draft the follow-up email · Confirm the send date with Talbot · Rate scanner — daily ops check.
• View 3: the same 4 items as View 2; the question is only whether they nest.
• Bases block: 1 row — this file.

Render check for Talbot

Open in Reading view. Three questions, in order of importance:

1. View 3 — does the hierarchy survive the filter? Nested or flat?
2. View 1 — is the Item column now clean (no trailing abc A status WIP … pills)?
3. View 2 — does the Parent column populate, or error/blank?