feat(viewer): expose org/toolchain layers in the applicability picker#1105
feat(viewer): expose org/toolchain layers in the applicability picker#1105kunickiaj wants to merge 2 commits into
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 07cf06c50b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Previous slice (the G1.3 read-only badge patch) showed org/toolchain state truthfully but didn't let users pick those layers. This change extends the dropdown to all four layers and prompts via the existing sync input dialog for a free-text key when the user picks org or toolchain. Key normalization - normalizeKey now lowercases and collapses internal whitespace in addition to trimming. Without this, the free-text picker would let peers fragment a single toolchain into "PNPM" / "pnpm" / "pnpm " entries that the band treats as three distinct layers. Toolchain keys are lowercase by convention; org keys are treated as identifiers in the same namespace for simplicity (mixed-case org names can be picked up by a smarter picker in the follow-up). UI behavior - Dropdown lists all four layers; selecting toolchain or org opens the sync input dialog (free-text initially, with a suggestions follow-up filed separately). - Broadening confirmation triggers on any transition out of project scope and reuses the existing sync confirm dialog with layer-specific copy. - The dropdown's option label for org/toolchain explicitly shows "(no key) — needs a … key" when the current value lacks a scope_key, so a malformed peer row reads as repair-needed rather than as an unset prompt. - Success notice now says "across every project on the pnpm toolchain" / "across every project in the acme organization" instead of leaking the raw enum name. Tests - 2 new applicability validator tests covering case folding and whitespace collapse; existing 15 tests untouched and still passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ope_key Codex review on PR #1105 flagged that saveAppliesTo's "same layer + same key = no-op" early-return prevented users from repairing rows that arrived from a peer with applies_to=org/toolchain but a null applies_to_key (malformed payload, or a peer that wrote before the schema normalization landed). The dropdown labels those rows as "(no key) — needs a … key", but selecting the same layer to fix the state was a no-op. Tighten the short-circuit: it's still a no-op when the layer + key pair already represents a valid state, but if the current row is org/toolchain WITH a missing/empty key, re-selecting the same layer falls through to the key-input dialog so the user can supply the key without bouncing through another scope first. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
07cf06c to
0a22e9b
Compare
|
Scrapping the layered sticky-rules feature stack. The manual user-pinning premise — "user finds a memory in the feed and clicks a dropdown to broaden its scope" — is friction nobody will reach for. The valuable sticky rules ("use fish shell", "no praise filler") are not memories users would find and pin; they are recurring patterns the observer should infer, and the canonical homes for them already exist ( Salvaging the one pre-existing bug surfaced during this work as a focused standalone PR: the silent |

Description
Extends the applicability picker in
FeedItemCardto expose all fourapplies_tolayers (project / user / org / toolchain). Backend has supported all four since #1102; the v1 viewer dropdown only offered project↔user because org/toolchain need ascope_keyinput. This slice fills the gap and tightens key normalization so the free-text input doesn't fragment.openSyncInputDialogfor a free-text scope_key. Cancel aborts.normalizeKeynow lowercases and collapses internal whitespace in addition to trimming. Without this,"PNPM"/"pnpm"/"pnpm "would fragment a single toolchain into three distinct layers. Toolchain keys are lowercase by convention; org keys join the same namespace for simplicity. A smarter org casing story is filed as a follow-up alongside the suggestions picker.Toolchain (no key) — needs a toolchain keyinstead of the unset-prompt label.…across every project on the pnpm toolchain/…across every project in the acme organizationrather than leaking the raw enum name.Type of Change
Testing
pnpm run tsc,pnpm run lint,pnpm run test) — workspace 1992/1992moveMemoryProjectflow. Pre-commit reviews flagged the normalization gap (would have shipped a fragmentation footgun), the leaky raw-enum notice grammar, and the misleading "pick a…" label for missing-key rows — all addressed before commit.Checklist
pnpm run lintpasses for touched files)Known limitations (follow-ups filed)
GET /api/memories/applies-to-keys?layer=…endpoint feeding the dialog'ssuggestionsfield is filed as a follow-up so existing keys can be picked instead of re-typed.