Gold warehouse views captured via `table` land as `type: Table`; `view` CLI is easy to miss

[RichardHightower]

Summary

capture_view exists, but the path agents actually use for “here is a gold object name” is dekc_capture.py table --layer gold. Coverage-skeptic: ten x_vw* / vw* shells are Table, only PlannedDeliveries should be. walk_lake infers view from CREATE VIEW or /views/ in the path — Fabric gold views have neither in git.

capture_view also lacks --schema / --source / --columns-json parity with table.

Repro

python3 scripts/dekc_capture.py table --name x_vwDimPronumber --layer gold --schema data_central_wh.gold
# type: Table, path tables/gold-x-vwdimpronumber.md

Expected

• --kind view on table CLI, or auto-detect vw / x_vw / CREATE VIEW.
• View capture should set schema, fqn, optional sourced_from with the same evidence rules as tables.
• Skill: warehouse gold vw* → View, not Table.

Code

capture_table always type: Table. walk_lake view detection is filesystem-only (dekc_walk.py is_view = "create view" in sql.lower() or "/views/" in path).

---

Found on: DEKC 0.4.1 (GitHub Latest 2026-08-24), mixed PKC+SAC+DEKC second brain, Azure Fabric reverse-engineering walk.
Not a sample-knowledge issue. Repro used live capture scripts from spillwave-second-brain cache data-engineering-knowledge-capture/0.4.1/.

[RichardHightower]

Fixed in 0.4.2 via #45. table --kind auto (default) treats vw* / x_vw* / CREATE VIEW as View. view has --schema / --source / --columns-json parity.