feat: workspace review β skill publish waits for the owner, review status, decision notices, served-version skill sync
Issue for this PR
No GitHub issue; this is the CLI side of workspace review. Backend: AltimateAI/altimate-backend#7740 and AltimateAI/altimate-backend#7741. Web app: AltimateAI/altimate-frontend#3687. Engine: AltimateAI/altimate-mcp-engine#280.
Type of change
- Bug fix
- New feature
- Refactor / code improvement
- Documentation
What does this PR do?
When a workspace owner turns review on, members' skills reach the team only after the owner approves them in the web app. The CLI only shows status; it has no approve or reject.
skill publish: uploads to your own skills, then submits to the linked workspace. The owner's skill attaches directly; a member's waits for review. The command prints what the service answered (sent, already waiting, already approved) and records the request as from the CLI.--replacefinds your skill among your own skills (?mine=true), so a skill whose first submission was rejected is still found.workspace review status: lists your requests on the linked workspace (kind, status, new or update, reviewer and reason, expired). Read-only.- Decision notices: the session server checks every 5 minutes and keeps the 50 most recent decisions per account and workspace, and the TUI shows each once. Behaviour change worth knowing: the renderer lease is gone, so the check runs whenever workspaces are on and you are signed in. The first replay in a project that has never seen notices marks existing ones as seen without showing them, as rule notices already do.
- Your pending rules are delivered to your own sessions under "Your rules pending review".
- Skill sync serves the version the workspace serves you: the approved version, or your own waiting one.
- Detail and file reads are bound to the listed
revision, and a 409revision_changeddiscards that skill for this sync, so a project never mixes files from two versions. - A copy is withdrawn when the server has said its version is no longer served: the list names another revision, a read is refused naming another, or the list no longer names a skill synced from a review-aware server. This holds even when every other download fails, and on an abandoned run.
- A plain failure (network, 401/403, 5xx) keeps a copy the server has not contradicted.
- The snapshot swap and that withdrawal take the same cross-process lock, and a withdrawal only removes a copy still identical to the one judged obsolete.
- Detail and file reads are bound to the listed
- Docs: CLI usage, skills, learn.
How did you verify your code works?
- Tests:
bun test test/altimate/workspace test/altimate/rules test/altimate/learn: 3,580 pass, 1 fail. The failure isdatamate_manager write that races the link, which fails onmainin this environment too. - Mutation checks: the new skill-sync tests (dropped skill, 409 naming a newer revision, abandoned run vs a copy another process replaced) each fail when their fix is removed.
bun run typecheckis clean.- End to end against a local backend (hackdev tenant, owner admin, member sarav):
skill publishas a member and as the owner, a duplicate, andworkspace review status;workspace refreshdelivers the author's waiting skill to their project;- after the owner rejects it, the next refresh removes it;
- the author and the owner sync different versions (pending v3 vs approved v2).
Cost side effects
None. The decision-notice check is one small API call every 5 minutes per signed-in session server with workspaces on. Skill sync makes the same number of requests as before, with one extra query parameter.
Screenshots / recordings
The CLI output is text. The web review screens are in AltimateAI/altimate-frontend#3687.
Checklist
- I have tested my changes locally
- I have not included unrelated changes in this PR
- I checked for cost side effects (model calls, queries or cloud resources that grow with user data) and described them, or wrote "none"
π€ Generated with Claude Code
Summary by cubic
Adds the CLI side of workspace review: when a workspace owner turns review on, members' skills reach the team only after the owner approves them in the web app.
skill publishuploads to your own skills, submits to the linked workspace, and prints what the service answered (published, sent, already waiting, already approved); the whole flow runs under one captured credential.--replacefinds your skill among your own, so a skill whose first submission was rejected is still found, and a member on a server without review keeps the upload but is told the submission failed.- Adds read-only
workspace review status [--json], listing your requests with kind, status, reviewer, and reason, and resolving the link likeworkspace status. - Decision notices for your skill and knowledge submissions are polled every 5 minutes, kept per account and workspace, and shown once in the TUI. The renderer lease is gone, so the check runs whenever workspaces are on and you're signed in; the first replay in a project that never saw notices marks existing ones as seen. Paging or read failures never let a pending request go silent, and replay never waits on the network.
- Your pending rule proposals are delivered to your own sessions under "Your rules pending review"; a pending edit keeps the pin of the rule it replaces, and proposals dropped from a pull are reported in the sync status.
- Skill sync serves the version the workspace serves you: reads are bound to the listed
revision, a 409revision_changeddiscards that skill, and a copy is withdrawn when the server says its version is no longer served β including when every download fails and on abandoned runs. Swaps and removals take the cross-process snapshot lock, so a superseded run keeps a newer snapshot and withdraws only what its own read said is no longer served. A plain failure keeps a copy the server has not contradicted.
Summary by CodeRabbit
- New Features
- Members can submit skills and knowledge bases for workspace review, with approval or rejection updates surfaced in the TUI.
- Added
skill publish --jsonand a read-onlyworkspace review statuscommand with text and JSON output. - Pending workspace rule proposals appear separately; proposed edits replace existing rules in the delivered view, while retirements have no effect until approval.
- Bug Fixes
- Workspace skill sync respects server-provided revisions and avoids retaining outdated copies when versions change or skills are withdrawn. Concurrent syncs preserve newer snapshots.
- Skill replacement finds the userβs same-name skills without adopting skills attached only to other workspaces.
- Documentation
- Expanded guidance on review delivery, publishing outcomes, status checks, and replacement limitations.