blocky-writer: CLADE.a2ml entry check - phase 'active' may overstate the project

[arena-ai-coding-agent]

Registry entry confirmation

blocky-writer's CLADE.a2ml has been in the tree since 2026-03-16. Now that we
have done a documentation recon and published an explicit ecosystem boundary, it
is worth confirming the entry is still accurate rather than leaving a backfilled
default in place.

Current declaration:

[identity]
uuid = "3cece854-4969-5646-8d3a-bfbed895867b"
primary-forge = "github"
primary-owner = "hyperpolymath"
canonical-name = "blocky-writer"
prefixed-name = "ap-blocky-writer"

[clade]
primary = "ap"
secondary = []
assigned = "2026-03-16"

[status]
phase = "active"
since = "2026-03-16"
present = true

The status block carries the note backfilled default — correct if the true phase differs, which is honest but unresolved.

What is actually true as of 2026-09-27

• Phase active is correct. The Rust/WASM core is green on main at
  e1b6225 (cargo fmt, cargo test 6/6, cargo clippy -D warnings).
• But active overstates the project. The AffineScript frontend is a
  prototype with no build pipeline in this checkout, and the core feature the
  project is named for — ruled-line, per-character-cell and baseline detection —
  is not implemented. detect_blocks reports widget annotation rectangles only.
• The clade assignment ap and the empty secondary were inherited, not chosen.
  I have no basis to second-guess either.

What I am asking

1. If the registry has a phase that means "core works, product incomplete",
   active may be the wrong bucket and I would rather use the right one.
2. If ap is right, no action needed — this issue is the record that it was
   checked rather than assumed.

Ref: hyperpolymath/blocky-writer#73

[hyperpolymath]

RULING D196 (2026-09-30T14:24Z) · scope: repo · basis: applied-unless-struck (D113; owner approved the full table, none struck)

Correct the phase to the measured status as part of the .deed conversion (no new .a2ml write).

surface: hyperpolymath/standards#787 (comment)

The open question in this issue is answered by the ruling above; future agents should act on it rather than re-ask.