Skip to content

docs: fix CHANGELOG lens-proposal drift (no delete_lens kind added — pattern report inside)#94

Merged
claude-dataviking merged 1 commit into
mainfrom
feat/delete-lens-proposal
Jul 15, 2026
Merged

docs: fix CHANGELOG lens-proposal drift (no delete_lens kind added — pattern report inside)#94
claude-dataviking merged 1 commit into
mainfrom
feat/delete-lens-proposal

Conversation

@claude-dataviking

Copy link
Copy Markdown
Contributor

What

Two CHANGELOG corrections from the lens-capability audit, both in [Unreleased]:

  1. False hosted-MCP claim fixed. The positioning-lenses entry claimed add_lens/update_lens proposals are authored "over the hosted MCP server — vault_propose". That is not true today: the cloud vault_propose kind allowlist contains no lens kinds (a cloud-side fix is queued separately). Reworded to what is true — the kinds exist in the local proposal store and CLI (traitprint proposals add); hosted-MCP propose support is pending.
  2. Stale line removed. The vault import-story-bank entry still said "no lens proposal kind exists yet" — superseded by the lens entry in the same Unreleased section. Replaced with the accurate reason: the importer does not stage lens proposals.

What was deliberately NOT done: delete_lens proposal kind

The audit also flagged that PROPOSAL_KINDS has no delete_lens while VaultStore.remove_lens and vault lens remove exist. Before adding one, I checked whether delete proposal kinds are a pattern for any entity type:

  • src/traitprint/proposals.py PROPOSAL_KINDS: only add_*/update_* plus update_profilezero delete_* kinds for any entity.
  • The versioned contract (docs/schema/vault-v1/vault-v1.schema.json $defs/proposal kind enum): same — no delete kinds.

So proposal-driven deletion does not exist anywhere in the system; deletion is deliberately a local, direct-CLI-only operation. Adding delete_lens unilaterally would invent a new contract pattern (and, per the "don't drift from cloud" constraint in CLAUDE.md, would need coordination with traitprint-cloud plus a contract revision). If proposal-driven deletion is wanted, it should be designed once for all entity types via an issue + contract revision, not bolted onto lenses alone.

Gates

  • pytest -q: 1028 passed, 3 skipped
  • ruff check src/ tests/: clean
  • mypy src/: clean

🤖 Generated with Claude Code

Two corrections in [Unreleased], both from a lens-capability audit:

- The lenses entry claimed add_lens/update_lens proposals work "over
  the hosted MCP server — vault_propose". False today: the cloud
  vault_propose kind allowlist has no lens kinds (cloud fix queued
  separately). Reworded to what is true — the kinds exist in the
  local proposal store and CLI; hosted-MCP propose support is pending.
- The vault import-story-bank entry still said "no lens proposal kind
  exists yet", stale since the lens kinds landed in this same
  Unreleased section. Replaced with the accurate reason (the importer
  does not stage lens proposals).

No delete_lens proposal kind is added: no delete_* proposal kind
exists for any entity (in code or the vault-v1 $defs/proposal enum) —
deletion is deliberately CLI-only (vault lens remove), so adding one
unilaterally would invent a new contract pattern.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@claude-dataviking
claude-dataviking merged commit fbdaf4e into main Jul 15, 2026
4 checks passed
@claude-dataviking
claude-dataviking deleted the feat/delete-lens-proposal branch July 15, 2026 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants