Repository navigation
feat: team rules from a linked Altimate workspace in Codex sessions - #7
saravmajestic wants to merge 4 commits into
Conversation
- Workspace-rules hooks (SessionStart, UserPromptSubmit, Stop) call `altimate-code learn hook <event>`. - Session start gives the agent the workspace's approved team rules, the number of proposals waiting, and new reviews. - Corrections are recorded with no model call. - The post-turn check runs in the background. - The hooks always exit 0, run the per-turn events only where workspace rules state exists, and print only the CLI's hook JSON. - `/altimate-code:rules` answers stored proposals through `learn proposals reply`. - Tests: a stub-CLI test for the hook script, and the resolver test covers the new command and `learn` calls. - README, CHANGELOG and PRIVACY (what the hooks read and send), version 1.2.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| [ -n "$ALTIMATE_BIN" ] || { echo "altimate-code CLI not found (tried altimate-code, altimate)" >&2; exit 127; } | ||
| PROPOSAL_ID='<the proposal id>' | ||
| WORDING="$(cat <<'ALTIMATE_RULE' | ||
| <the new wording> |
There was a problem hiding this comment.
WARNING: Heredoc body picks up the block's 3-space indent
The snippet sits inside a 3-space-indented list item, so this line renders as <the new wording>. cat <<'ALTIMATE_RULE' keeps leading whitespace, so WORDING starts with three spaces: the rule is stored with them and they count against the 140-character limit (possibly triggering invalid_text). Line 52 only says to move the closing ALTIMATE_RULE to column 0 — and if the agent misses that, the indented terminator is not recognised at all, so the heredoc runs to EOF, swallows the learn proposals reply call on line 50, and the script fails with a syntax error. Put the body at column 0 as well (or say "de-indent this whole block before running it"), and state it before the fence rather than after it.
| ``` | ||
| Keep `--edit="$WORDING"` in one argument (a wording that starts with `-` is otherwise read as a flag), and start the closing `ALTIMATE_RULE` line at the beginning of its line. For any other choice, run the same command with that flag instead of `--edit="$WORDING"` (and without the here-doc). | ||
|
|
||
| The JSON answer is `{"ok": true, "message": …, "closed": …}` or `{"ok": false, "code": …, "error": …}`. Show the `message` or `error` to the user as it is. Then: |
There was a problem hiding this comment.
SUGGESTION: Say which field each reply code lives in
Two shapes are given — {"ok": true, "message", "closed"} and {"ok": false, "code", "error"} — but the bullets below list closed: false, verification_flagged, invalid_text, refused, busy and not_open without saying whether they are code values or top-level keys. An agent that looks for verification_flagged as a top-level field will miss it and just print the error, instead of asking for the explicit confirmation that the follow-up --approve-anyway reply depends on. Spell it out: when ok is false, branch on code; when ok is true, check closed.
There was a problem hiding this comment.
Fixed in 1c54845: when ok is false, branch on code; when it is true, check closed.
|
|
||
| - The plugin itself collects **no data**. It is a routing layer (a skill, a slash command, and a static session hook) that tells Codex when to delegate a task to the altimate-code CLI installed on your machine. | ||
| - The plugin itself collects **no data**. It is a routing layer (skills, slash commands, and session hooks) that tells Codex when to delegate a task to the altimate-code CLI installed on your machine. | ||
| - In a project linked to an Altimate workspace with learning on, its workspace-rules hooks hand your messages and the session transcript to the local altimate-code CLI, which keeps corrections on your machine and may send a digest to your LLM provider to word a proposed team rule. A proposal reaches your workspace only when you send or approve it. See [Workspace rules](#workspace-rules). |
There was a problem hiding this comment.
WARNING: Effective date not revised for the new practices
This bullet and the new "Workspace rules" section add data flows (your messages, the session transcript, a redacted digest sent to your LLM provider, proposals and usage counts sent to the workspace), yet **Effective date:** July 18, 2026 stays unchanged. The policy's own "Changes to this policy" section says the effective date is revised "when our practices change", so the document now contradicts itself about which practices that date covers. Add a revision line (e.g. "Revised October 30, 2026") so users can see what changed and when.
| - **Command** — `commands/review.md` — `/altimate-code:review [scope]` explicit-review slash command; scope can be empty (working tree), a commit SHA, a branch name, or a GitHub PR URL / number | ||
| - **Hook** — `hooks/hooks.json` + `hooks/altimate-code-session-start.sh` — SessionStart capability description (static text only; no side effects) | ||
| - **Command** — `commands/rules.md` — `/altimate-code:rules` to answer proposed team rules | ||
| - **Hooks** — `hooks/hooks.json` + `hooks/altimate-code-session-start.sh` — SessionStart capability description (static text only; no side effects); `hooks/altimate-code-workspace-rules.sh` — the [team rules](#team-rules) hooks (SessionStart, UserPromptSubmit, Stop), which call `altimate-code learn hook <event>` and never block or fail the session |
There was a problem hiding this comment.
SUGGESTION: "never block" is not true for session start
session-start is synchronous: hooks.json waits up to 15 s for altimate-code learn hook session-start before the session context is built (the script's own header calls it a "bounded sync"). Only user-prompt-submit and stop are detached. Say "the per-turn hooks never block; session start makes one bounded synchronous call", so a stalled session start from a slow or unreachable CLI is not a surprise.
There was a problem hiding this comment.
Fixed in 1c54845: the per-turn hooks never block; session start makes one bounded call (at most 15s).
| - **"Remember this as a team rule: …"** in a task handed to altimate-code is proposed the same way. | ||
| - **`/altimate-code:rules`** shows the proposals waiting for you, the team rules, and the status of the rules you proposed. For each proposal you choose: send it to the workspace owner's review (or approve it, if you are the owner), edit the wording, save it as a memory, or "Not a rule". Nothing reaches teammates until the owner approves it. | ||
|
|
||
| The same commands work in a terminal: `altimate-code learn proposals`, `altimate-code learn proposals reply <id> --send`. This needs an altimate-code release with workspace rules. |
There was a problem hiding this comment.
SUGGESTION: altimate-code is not on PATH for curl installs
The Prerequisites section and the troubleshooting table both note that curl/PowerShell installs may expose only altimate. A user on that install gets command not found from altimate-code learn proposals. Use the same parenthetical as the rest of the README (altimate learn proposals on installs without altimate-code), or show the altimate form here.
| - Team rules from a linked Altimate workspace apply in Codex sessions. At session start the plugin gives Codex the workspace's approved rules for the repository, the number of proposed rules waiting for you, and the owner's reviews of your proposals since your last session. | ||
| - Corrections you make to Codex are recorded locally (UserPromptSubmit, no model call). After a turn, altimate-code checks them in the background (Stop) and keeps a proposed rule when you corrected the same topic in two sessions or corrected a team rule Codex was given. | ||
| - `/altimate-code:rules`: answer proposed rules (send for review, approve as owner, edit, save as memory, or "Not a rule"), and see the team rules and the review status of your proposals. | ||
| - The hooks run only in a linked project with learning on. They need an altimate-code release with `learn hook`; with an older one they do nothing. |
There was a problem hiding this comment.
SUGGESTION: SessionStart is not gated on the linked project
"The hooks run only in a linked project with learning on" holds for the per-turn events, which gate on .altimate-code/learn/workspace-rules/rules.json. The session-start hook invokes altimate-code learn hook session-start in every project — it has to, in order to learn whether the project is linked — and the linked/learning gates are applied by the CLI, not before the call. Reword to match the code (PRIVACY.md already words this correctly).
| esac | ||
| ;; | ||
| user-prompt-submit|stop) | ||
| ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)" |
There was a problem hiding this comment.
SUGGESTION: The gate and the CLI invocation resolve different roots
The existence check uses git rev-parse --show-toplevel, but the CLI on line 40 is spawned with the current directory and no --dir. The two only agree if the CLI independently walks up from $PWD to the same root; if it does not, a session started in a subdirectory (or a dbt project nested inside a monorepo git root) either never fires the per-turn events or fires them somewhere without state. The new test's "works from a subdirectory" case passes only because the stub ignores its cwd. Pass --dir "$ROOT" (or cd "$ROOT" before the spawn) so the gate and the call agree, and have the stub assert the directory it ran in.
| [ "$(hook "$WORK/project" "$event" "$BIN:$SYS")" = "0|" ] || fail "$event without rules state did not exit quietly" | ||
| done | ||
| sleep 0.5 | ||
| [ ! -s "$LOG" ] || fail "per-turn events ran the CLI without workspace rules state: $(cat "$LOG")" |
There was a problem hiding this comment.
SUGGESTION: Fixed 0.5 s sleep makes the negative assertion racy
If the hook wrongly spawns the CLI without workspace-rules state, the stub may not have appended to $LOG within 0.5 s on a loaded machine, so this check passes anyway. Wait deterministically — e.g. have the stub touch a sentinel as its first action and poll for its absence over a longer bounded window, or reuse an await_log-style loop — instead of a single fixed sleep.
There was a problem hiding this comment.
Fixed in 1c54845: the stub records a sentinel as its first action, and the negative checks are made deterministic.
Code Review SummaryStatus: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (10 files)
Reviewed increment Fix these issues in Kilo Cloud Previous Review Summaries (3 snapshots, latest commit adad91a)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit adad91a)Status: 10 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (9 files)
Reviewed increment Fix these issues in Kilo Cloud Previous review (commit 3f97ab6)Status: 9 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (9 files)
Reviewed increment Previous review (commit d713c51)Status: 8 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (9 files)
Verified sound: the per-turn background spawn genuinely returns immediately ( Reviewed by deepseek-v4.1-flash-1017 · Input: 65.5K · Output: 39.6K · Cached: 878.1K |
…terrupted answer - README and CHANGELOG: "Remember this as a team rule: …" said to the agent waits as a proposal, and rule drafting needs altimate-code's own model. - `/altimate-code:rules`: handles an answer that stopped part-way (`not_available` … "was being answered with"). - Codex: the sandbox has no network, so a proposal sent from `/altimate-code:rules` is queued until the next turn. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| - A message saying the proposal was queued and not sent yet: normal inside Codex's sandbox, which has no network; it is sent after the user's next turn. | ||
| - `busy`: another session is answering it; skip it for now. | ||
| - `not_open`: it was already answered or closed; move on. | ||
| - `not_available` saying it "was being answered with" another action: an earlier answer stopped part-way; offer to finish it with that action. |
There was a problem hiding this comment.
SUGGESTION: A queued reply is itself an answer that "stopped part-way"
The two new bullets overlap without saying which one wins. Line 59 says that inside Codex's sandbox a reply is accepted locally and queued, not sent. That is exactly a proposal left "being answered with" an action until the queue drains after the turn. An agent that hits not_available in that state and follows this bullet re-issues the same action (e.g. --send), so once the queued copy flushes the proposal can be queued twice or the owner sees a duplicate. This also matters for --approve: "finish it with that action" must not be read as permission to repeat --approve-anyway without the explicit confirmation required by line 56 for verification_flagged. Say to check for the queued case first and to re-apply the verification_flagged confirmation when finishing an approve.
There was a problem hiding this comment.
Fixed in 1c54845: a queued answer counts as answered and is never re-sent; --approve-anyway always needs fresh confirmation.
- Session start runs the CLI only where workspace rules state exists, or where the workspace link cache names the repository or a folder inside it. Elsewhere the hook costs nothing. - The per-turn hooks share the same state check. The CLI still runs from the host's directory: a link can be for a folder inside the repository. - README: direct "remember" needs "team rule" wording. `/altimate-code:rules`: a here-doc delimiter note. - Hook test covers the pre-filter and a link for a folder inside the repository. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| # Only a repository with workspace rules state, or one the workspace link cache names (the repository or a folder | ||
| # inside it), can have team rules: elsewhere the CLI is not started at all. | ||
| if [ ! -f "$STATE" ]; then | ||
| CACHE="${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json" |
There was a problem hiding this comment.
WARNING: Session start now depends on an undocumented private cache file
This path and its bindings key schema are owned by the CLI and appear nowhere else in the repository (no README, PRIVACY or CHANGELOG mention), and the test writes the file itself, so the real location and format are never exercised. Node tooling commonly resolves its state directory to ~/Library/Application Support on macOS and %LOCALAPPDATA% on Windows rather than XDG, and a rename or schema change on the CLI side has the same effect: session start silently stops running the CLI in every project. The user then gets no team rules, no "check failed" notice and no diagnostic, because the hook always exits 0. Document the contract next to the plugin's version requirement, fall back to the CLI when .altimate-code/ exists, or assert the path in a test that does not create the file.
There was a problem hiding this comment.
Partly: see the matching thread on altimate-claude-plugin#13. The location is the CLI's xdg-basedir state path on every platform, now documented in PRIVACY.md and the hook comment.
| if [ ! -f "$STATE" ]; then | ||
| CACHE="${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json" | ||
| REAL="$(cd "$ROOT" 2>/dev/null && pwd -P)" | ||
| [ -n "$REAL" ] && grep -qF "\"$REAL" "$CACHE" 2>/dev/null || exit 0 |
There was a problem hiding this comment.
WARNING: The path match has no boundary
grep -qF "\"$REAL" accepts any quoted path that merely starts with REAL, so a binding for /work/acme-old also matches REAL=/work/acme: the CLI is started at session start in an unlinked project and pays up to the 15 s synchronous timeout this commit exists to avoid. In the other direction the match is literal and REAL is pwd -P (symlinks resolved) while the cache holds whatever the CLI recorded, so a linked project reached through a symlink or a git worktree misses and loses its team rules with no message. Match "$ROOT"/"$REAL" only when followed by " or /, and add negative tests for a sibling directory sharing the prefix and for a link recorded on a parent folder.
There was a problem hiding this comment.
Fixed in 1c54845: exact key with both quotes, JSON-escaped, native paths on Windows. Negative tests added.
| esac | ||
| ;; | ||
| user-prompt-submit|stop) | ||
| [ -f "$STATE" ] || exit 0 |
There was a problem hiding this comment.
SUGGESTION: The per-turn gate and the CLI can still resolve different project roots
The new comment (lines 29-30) says a link may be for a folder inside the repository, and session start now accepts that through the cache; but $STATE is always <git toplevel>/.altimate-code/learn/workspace-rules/rules.json. If the CLI keeps workspace-rules state beside the linked folder (repo/dbt/.altimate-code/…) instead of at the git root, user-prompt-submit and stop exit here before recording anything: the session receives the team rules but corrections never become proposals, silently. The test cannot catch it, because the stub ignores its cwd and rules.json is only ever created at the repo root. Either state that the CLI always writes this state at the git root, or check the linked path as well.
There was a problem hiding this comment.
No change needed: the CLI keeps workspace-rules state at the repository root (Instance.worktree), even for a link made for a subfolder, so the per-turn gate and the CLI agree. A comment in the hook now says so.
hkaltai
left a comment
hkaltai
left a comment
There was a problem hiding this comment.
Peer review: APPROVE (with minor comments)
Reviewers: lead (Claude), Claude (fresh claude -p session), Codex (gpt-6.1-sol), with one convergence round.
The hook wrapper is defensive: every path exits 0, only the CLI's JSON is passed through, per-turn calls are detached with every file descriptor closed, and repositories without rules state or a link start no CLI. The /altimate-code:rules flow offers at most 4 choices. Nothing blocks merge here. The minor comments are inline, and the PRIVACY.md wording should be settled before release.
Dependency: merge and release after AltimateAI/altimate-code#1626, which has an open MAJOR. Without a configured model, the background Stop check auto-registers for Altimate Base and sends the digest with no disclosure. That affects what this PRIVACY.md can promise.
A linked-worktree root mismatch was raised, then withdrawn in convergence: the CLI's Instance.worktree is the --show-toplevel checkout, which matches $ROOT here.
Nits (consolidated)
plugins/altimate-code/hooks/altimate-code-workspace-rules.sh:29-30: the comment "Run from the host's directory, not the repository root" sits right above the line that computes the repository root, so it reads as contradicting it. Suggest: "$ROOTonly locates the state file; the CLI runs in the host's directory (nocd), because a link can be for a folder inside the repository."plugins/altimate-code/hooks/altimate-code-workspace-rules.sh:41:grep -qF "\"$REAL"doesn't JSON-escape the path (a directory containing"or\never matches) and is a prefix match (/x/appmatches/x/app-old). The walk-up fix in the inline comment covers both.- Docs mix
altimate learn …andaltimate-code learn …for the same commands (README and PRIVACY). Pick one. tests/workspace-rules-hook.sh: the slow stub's background processes outlive the test and are still sleeping when the trap deletes$WORK. Kill them before cleanup.- README: a new clone or worktree gets no team rules until altimate-code has run (or been linked) in that checkout, because both the gate and the CLI read only the directory-keyed bindings cache. Worth one line.
Scope vs ticket: cannot verify, because there's no ticket reference. Unrelated files: clean. Naming: clean, apart from the mixed command names above.
🤖 Generated with Claude Code
| if [ ! -f "$STATE" ]; then | ||
| CACHE="${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json" | ||
| REAL="$(cd "$ROOT" 2>/dev/null && pwd -P)" | ||
| [ -n "$REAL" ] && grep -qF "\"$REAL" "$CACHE" 2>/dev/null || exit 0 | ||
| fi |
There was a problem hiding this comment.
MINOR — The gate lets through a child-folder link that the CLI can't find from the repo root
if [ ! -f "$STATE" ]; then
CACHE="${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json"
REAL="$(cd "$ROOT" 2>/dev/null && pwd -P)"
[ -n "$REAL" ] && grep -qF "\"$REAL" "$CACHE" 2>/dev/null || exit 0
fi
When only dbt/ is linked and the session starts at the repository root, this check passes (the key starts with $REAL). But the CLI's RulesService.linked() (altimate-code rules/service.ts:59-67) only walks up from the cwd to the root, so it returns not linked. The CLI starts, waits up to the first-pull budget, and gives no rules. The comment ("or a folder inside it") and the test at tests/workspace-rules-hook.sh:50 ("started from the repository root: the CLI runs") pass only because the stub always answers.
Suggested fix: mirror the CLI. Walk from pwd -P up to $ROOT, matching "\"$DIR\"" with the closing quote at each step; that also removes the /x/app vs /x/app-old prefix overmatch. Or teach the CLI to look below the cwd. Then change the test to start inside project/dbt/models, and add a negative case for a root start with only a child folder linked.
|
|
||
| ## Workspace rules | ||
|
|
||
| These hooks act only in a project linked to an Altimate workspace, with learning on, workspaces on and you signed in to Altimate. Otherwise the session-start hook reads only local altimate-code state and sends nothing, and the per-turn hooks do not run the CLI at all in a project without workspace rules state. |
There was a problem hiding this comment.
MINOR — The learning-off guarantee is stronger than the code
These hooks act only in a project linked to an Altimate workspace, with learning on, workspaces on and you signed in to Altimate. Otherwise the session-start hook reads only local altimate-code state and sends nothing, ...
RulesHost.start() checks rulesEnabled() (the learn switch and workspaces) before the pull. But the workspace's "Learn from sessions" setting and capture (learn disable sets capture=false) are checked only afterwards, in on(). So with either opt-out from line 36, a signed-in, linked project can still pull from Altimate at session start. Also, the per-turn hooks pass every prompt and the transcript path to a local CLI process wherever rules.json exists, even after learn disable, sign-out or unlink. The CLI then drops them, so nothing leaves the machine, but the wording implies the hooks stop.
Separately, the digest goes to "your configured LLM provider" only if one is configured. Otherwise the CLI currently auto-registers Altimate Base (see the MAJOR on AltimateAI/altimate-code#1626).
Suggested fix: narrow the wording to what is gated: capture and drafting are off; a rules pull still happens unless ALTIMATE_LEARN=0. Or change the CLI to check the workspace setting before pulling. Optionally, skip the per-turn hooks early on ALTIMATE_LEARN=0.
There was a problem hiding this comment.
Fixed in 1c54845; see the matching thread on altimate-claude-plugin#13.
|
|
||
| - The plugin itself collects **no data**. It is a routing layer (a skill, a slash command, and a static session hook) that tells Codex when to delegate a task to the altimate-code CLI installed on your machine. | ||
| - The plugin itself collects **no data**. It is a routing layer (skills, slash commands, and session hooks) that tells Codex when to delegate a task to the altimate-code CLI installed on your machine. | ||
| - In a project linked to an Altimate workspace with learning on, its workspace-rules hooks hand your messages and the session transcript to the local altimate-code CLI, which keeps corrections on your machine and may send a digest to your LLM provider to word a proposed team rule. A proposal reaches your workspace only when you send or approve it. See [Workspace rules](#workspace-rules). |
There was a problem hiding this comment.
MINOR — Effective date (line 3) unchanged after a material change, anchored here because line 3 isn't in the diff
**Effective date:** July 18, 2026
The policy now covers every prompt and the transcript, plus a digest sent to an LLM provider. The policy itself promises to revise the effective date when practices change. Set it to the 1.2.0 release date, and get the privacy sign-off the PR description asks for.
| cd "$(dirname "$0")/.." | ||
| HOOK="$(find "$PWD/plugins/altimate-code" -name '*workspace-rules.sh' | head -n1)" | ||
| [ -f "$HOOK" ] || { echo "FAIL: no workspace-rules hook script"; exit 1; } | ||
| grep -q "$(basename "$HOOK")" plugins/altimate-code/hooks/hooks.json || { echo "FAIL: hooks.json does not run $(basename "$HOOK")"; exit 1; } |
There was a problem hiding this comment.
MINOR — hooks.json is only checked by grepping for the script name
grep -q "$(basename "$HOOK")" plugins/altimate-code/hooks/hooks.json || { echo "FAIL: hooks.json does not run $(basename "$HOOK")"; exit 1; }
A typo in an event name (UserPromptSubmit/Stop), an argument (user-prompt-submit, which the script's case silently ignores), or a timeout would still pass. Parse it with python3 -c 'import json…' or jq, and assert each event runs the script with its matching argument and the 15/5/5 timeouts.
| - In a project linked to an Altimate workspace with learning on, its workspace-rules hooks hand your messages and the session transcript to the local altimate-code CLI, which keeps corrections on your machine and may send a digest to your LLM provider to word a proposed team rule. A proposal reaches your workspace only when you send or approve it. See [Workspace rules](#workspace-rules). | ||
| - When a task **is** delegated, your task text is passed to the altimate-code CLI, which sends it to an LLM provider to plan and execute the work — the Altimate LLM Gateway by default, or a provider you configure (BYOK). | ||
| - Warehouse queries, dbt commands, and file edits run **locally on your machine, under your credentials**. Your warehouse credentials are never sent to Altimate. | ||
| - The plugin ships as opt-in. Adding the marketplace does not enable the plugin — you must explicitly install it from Codex's `/plugins` browser and approve its SessionStart hook before any delegation happens. |
There was a problem hiding this comment.
MINOR — Consent wording still names only the SessionStart hook
... you must explicitly install it from Codex's `/plugins` browser and approve its SessionStart hook before any delegation happens.
1.2.0 also installs UserPromptSubmit and Stop hooks, and those are the ones that see every prompt and the transcript. Say "approve its hooks (SessionStart, UserPromptSubmit, Stop)" here and at line 75. In the README, mention that Codex may ask again after upgrading from 1.1.0.
There was a problem hiding this comment.
Fixed in 1c54845: PRIVACY (lines 16 and 75), SECURITY.md and the README's trust section now name SessionStart, UserPromptSubmit and Stop. The README also says Codex may ask again after upgrading from 1.1.0.
ralphstodomingo
left a comment
ralphstodomingo
left a comment
There was a problem hiding this comment.
Requesting changes to PRIVACY.md, which the description asks to have reviewed. The code reads fine. These are the places where the policy doesn't match what altimate-code does:
- What the digest contains. The "session transcript" row says "a bounded, redacted digest". The digest altimate-code builds (
packages/opencode/src/altimate/learn/digest.tsin altimate-code) holds the session's prompts, every tool call's input and output (up to 300 and 400 characters per call, so file contents, command output and warehouse rows), and the final reply, up to 24,000 characters in all. Redaction masks secrets only, not other data. The policy should say so. - Where it goes. "Your configured LLM provider" reads as Codex's provider (OpenAI). It's actually altimate-code's own model:
learn.model, else altimate-code's default (the Altimate LLM Gateway, or the provider configured for altimate-code). Name it, since for a Codex user it's a party that doesn't otherwise see the session. - Telemetry. "does not phone home and does not collect analytics" is true of the plugin itself, but the CLI the hooks start sends rules telemetry:
rules_sync,rules_delivered,rule_draftedandrule_proposal_shown(the last with the host session id). Add a row to the table, or point this section at "Usage telemetry" below. - Who turns learning on. "with learning on" doesn't say that, in a linked project, the workspace's "Learn from sessions" setting turns capture on for a member who hasn't made a choice of their own. The policy lists that setting as an off switch; it should also say the workspace owner can switch capture on with it.
- Effective date. The data flows changed, and "Changes to this policy" says the date is revised when practices change.
Smaller:
- In the description,
stacked on #1605links to this repository's own number 1605, not altimate-code's. Use AltimateAI/altimate-code#1605. - On Windows the session-start check of the link cache never matches. It greps for the Git Bash path (
/c/Users/...), but altimate-code keys the cache by the native path, JSON-escaped (C:\\Users\\...). So on Windows, session start only runs the CLI where workspace-rules state already exists. - The edit here-doc in
commands/rules.mdis indented inside its list item. Copied as written, the closing delimiter doesn't end it, or the wording picks up leading spaces (Kilo's thread). Showing the block flush left avoids both.
As the description says, this must merge and ship after an altimate-code release that has learn hook, and also after the changes requested on AltimateAI/altimate-code#1626.
Appendix: complexity delta
No TypeScript or Python in this diff (a shell hook, Markdown and JSON), so there's nothing to measure.
- `hooks/altimate-code-workspace-rules.sh`: at session start, walk from the host's directory up to the repository root and match each folder as an exact JSON key of the link cache (escaped, native form via `cygpath -w` on Windows), as the CLI does. A link for a subfolder no longer starts the CLI from the repository root, and `/x/app` no longer matches `/x/app-old`. - Skip every event with `ALTIMATE_LEARN=0` (or `false`). - Correct the comments on `$ROOT`, blocking and model calls per `Stop`. - `tests/workspace-rules-hook.sh`: parse `hooks.json` and check each event's argument and timeout; cover a start below a linked subfolder, a root start with only a subfolder linked, a sibling-prefix link, quote/backslash paths, Windows native keys and `ALTIMATE_LEARN`; replace the fixed sleep with a sentinel; stop the slow stub on exit. - `commands/rules.md`: show the edit here-doc flush left, branch on `code` when `ok` is false and on `closed` when it is true, and never repeat `--approve-anyway` without fresh confirmation. - `PRIVACY.md`, `README.md`: approving the plugin means approving its hooks (SessionStart, `UserPromptSubmit`, `Stop`); Codex may ask again after upgrading from 1.1.0. - `commands/rules.md`: a sandbox-queued answer is treated as answered and never re-sent, including when a later `not_available` names it. - `PRIVACY.md`: state what is gated by what, who can turn capture on, the digest's contents and caps, that it goes to altimate-code's own model rather than Codex's, and the rules telemetry the CLI sends; add a revision date. - `README.md`, `CHANGELOG.md`: `altimate learn …` throughout, bounded session start, start in the linked folder, new clones and worktrees, where proposals are answered, and the corrected gating. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| # paths written as JSON strings, so each folder is converted (`cygpath -w` on Windows) and escaped, and matched with | ||
| # both quotes, so `/x/app` never matches `/x/app-old`. | ||
| linked() { | ||
| local cache="${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json" |
There was a problem hiding this comment.
WARNING: The link-cache directory is still an unverified, hard-coded XDG state path
linked() reads ${XDG_STATE_HOME:-$HOME/.local/state}/altimate-code/altimate-workspace-bindings.json, but nothing in this repository proves the CLI writes its link cache there. The plugin's own troubleshooting table documents the CLI's global directory as ~/.local/share/altimate-code/ (a data root, not a state root), and on macOS/Windows a Node CLI normally resolves to ~/Library/Application Support / %LOCALAPPDATA%. A data-vs-state or platform difference means grep never finds the cache, so session start starts nothing in every newly linked repository. Because the hook always exits 0, the user gets no team rules, no warning and no diagnostic.
The new test cannot catch this: link() writes the cache at exactly the path the test sets through XDG_STATE_HOME, so it only proves the hook can read a file it created itself. Verify the real location against the paired altimate-code release (or ask the CLI for the cache path), and add a test that expects the cache at the CLI's location rather than creating it in the hook's location.
| done | ||
| [ "$(hook "$WORK/project" stop "$BIN:$SYS")" = "0|" ] || fail "stop with rules state did not exit quietly" | ||
| await_log "learn hook stop --host $HOST" || fail "stop with rules state did not run the CLI" | ||
| for _ in $(seq 20); do [ "$(grep -c . "$STARTED")" -gt 1 ] && break; sleep 0.1; done |
There was a problem hiding this comment.
SUGGESTION: This wait can only ever time out
The loop breaks when $STARTED has more than one line, but the next assertion requires exactly one (= "learn hook stop --host $HOST"). On a correct run it therefore always burns the full two seconds; on a broken run it breaks early only to fail the following line, so it does not wait for anything meaningful. await_log has already confirmed the positive stop landed (the stub appends to $STARTED before it reads stdin and writes $LOG), so the loop can be dropped. If the intent is to catch a stray background call, use a deterministic sentinel or a bounded await_absent that also covers calls arriving after the assertion instead of sleeping for a second line that must not exist.
|
Review round addressed in 1c54845 (it also names all three hooks in the consent wording, SECURITY.md and the README). Each inline thread has a reply. PRIVACY.md, for ralphstodomingo's points 1–5 and hkaltai's comments:
Legal sign-off is still pending. Smaller points:
hkaltai's nits:
Dependency: merge and release after altimate-code#1626 ships in a release; the no-model and gating fixes are there. 🤖 Generated with Claude Code |
Summary
Team rules from a linked Altimate workspace now apply in Codex sessions. This needs altimate-code with
learn hook(AltimateAI/altimate-code#1626, which builds on the merged AltimateAI/altimate-code#1605). Merge and release after #1626 ships in an altimate-code release. With an older altimate-code the hooks do nothing: the session-start output is dropped unless it is the hook's JSON.SessionStart,UserPromptSubmit,Stop) callaltimate-code learn hook <event>with the host's hook input on stdin..altimate-code/learn/workspace-rules/rules.jsonexists./altimate-code:ruleslists the stored proposals, the team rules and your proposals' status, asks with numbered choices in chat (Codex has no question tool), and answers throughlearn proposals reply.Test plan
bash tests/resolve-cli.sh(now coverscommands/rules.mdandlearncalls)bash tests/workspace-rules-hook.sh(new, stub CLI):🤖 Generated with Claude Code