feat(amicode): context tree marks proprietary vault context locked by kateebonner · Pull Request #84 · harmoniqs/opencode

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner · 2026-07-28T18:32:50Z

Stacked on #83 (merge that first).

What

Two honesty fixes to the context tree's interactivity, from Kate's live testing:

The cursor now tells the truth. Only nodes a click actually opens (project files, browsable vault files) wear the pointer. Turn numerals, skills, agents, and bash actions — which have nothing to open — show the pan cursor (previously turns showed a pointer that clicked into nothing). The click-acknowledgement ring also only fires on openable nodes.
Proprietary context is locked, visibly and upfront. Files that live in a vault mount that refuses browsing (e.g. armonissima, kind team, fail-closed per Vault browsing: fail-closed by kind + public-only hackathon mode #69) render dimmed with a padlock glyph, wear a not-allowed cursor, and clicking them is a no-op. Keyboard navigation announces "locked — this vault does not allow browsing". Previously the click dead-ended in a Vault-panel refusal after the fact.

How

Server — GET /amicode/vaults stamps each mount with browsable, computed by the vault-browser's existing fail-closed law (browseAllowed deployment gate + mountBrowseRefusal kind/marker rules). Additive to the relayed wire shape; unparseable CLI bodies pass through untouched.
Panel — fetches the mount list once, derives a vaultLocked(mount) predicate: browsable:false → locked; mount missing from the list → locked (can't be browsed anyway); list unavailable or legacy server without the field → status quo (no lock claim we can't back).
Data — buildContextTree takes the predicate; vault leaves carry locked.
Engine — locked nodes: 0.3-alpha fill, fg-ink padlock drawn beside the label (shape signal, not color-only), not-allowed on hover, no select/ring on click.

Verification

Unit: vaults annotation suite (fail-closed law, ghost mounts, gate-off, junk passthrough) 20/20; context-tree data + engine 21/21.
Live (Playwright, real mount stack): /amicode/vaults stamps armonia-issimo/armonia-template browsable, armonissima not; synthetic-tree engine run verifies cursor law (pointer / not-allowed / grab), click no-op on locked, padlock + dim rendering in both themes.
Real-session regression: a session touching only the personal vault keeps all nodes openable (correctly un-locked).
Typecheck all packages + oxlint 0 errors.

🤖 Generated with Claude Code

Not every tree node was openable, but nothing said so: turn nodes wore a pointer cursor that clicked into nothing, and files in non-browsable (proprietary) vaults dead-ended in a Vault-panel refusal after the click. - GET /amicode/vaults now stamps each mount with `browsable`, computed by the vault-browser's fail-closed law (deployment gate + kind/marker rules) - tree leaves in a non-browsable mount render locked: dimmed dot, padlock glyph by the label, not-allowed cursor, click is a no-op, and keyboard nav announces "locked — this vault does not allow browsing" - cursor law is now honest everywhere: pointer only where a click opens something; grab (pan) on turns/skills/agents/actions; the click ring only fires on openable nodes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ance fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss

kateebonner merged commit 4fdaadb into kate/context-tree-drop-prompt-textJul 28, 2026
0 of 4 checks passed

kateebonner mentioned this pull request Jul 28, 2026
fix(amicode): land #84 on mainline (locked vault context) — stacked-merge miss #86
Merged