feat: add kata-backed pi tasks plugin by mariusvniekerk · Pull Request #15 · kenn-io/kata

mariusvniekerk · 2026-05-05T17:32:03Z

Summary

add an in-repo TypeScript Pi extension that exposes pi-tasks-style tools backed by Kata issues
map TaskCreate/List/Get/Update to Kata CLI operations and labels/links/owners
implement TaskExecute as a Kata claim/start bridge for pi-subagents with lifecycle comments and close/failure handling
include design/implementation docs and Vitest coverage for command translation, formatting, and lifecycle races

Validation

npm test
npm run typecheck
npm run build
git diff --check
GOFLAGS=-buildvcs=false go test ./...

Note: this worktree needs Go's suggested -buildvcs=false flag for the full suite because plain go test ./... fails while building helper binaries with VCS stamping.

roborev-ci · 2026-05-05T17:34:22Z

roborev: Combined Review (`d7e277e`)

Medium-risk lifecycle bugs remain in the Kata task execution flow; no High or Critical findings were reported.

Medium

plugins/pi-tasks-kata/src/kata.ts:117
claimForExecution allows tasks already labeled in_progress to be executed again, which can spawn duplicate subagents for the same Kata issue.

Fix: Reject execution when the task already has the in_progress label, or make execution idempotent by tracking and returning the existing run.
plugins/pi-tasks-kata/src/index.ts:110
If claimForExecution partially mutates the issue, such as assigning it or adding in_progress, and then a later claim step fails, claimed remains false, so cleanup is skipped and the task can be left claimed or in progress without any spawned agent.

Fix: Make the claim operation compensate its own partial mutations on failure, or expose partial-claim state so TaskExecute can call failExecution.
plugins/pi-tasks-kata/src/index.ts:123
recordAgentSpawn runs inside the same failure path as spawning. If only the spawn comment fails after the subagent was created, the code records execution failure and removes in_progress even though the agent is running.

Fix: Treat post-spawn comment failures separately, logging or surfacing them without marking the task execution as failed.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T17:48:51Z

roborev: Combined Review (`ad6352e`)

Verdict: Changes have 1 High and 2 Medium findings that should be addressed before merge.

High

Location: plugins/pi-tasks-kata/src/kata.ts:115
Problem: claimForExecution uses a check-then-mutate sequence (show, then assign, then label add) with no atomic guard, so two concurrent TaskExecute calls can both observe the task as not in progress and both spawn agents for the same Kata issue.
Fix: Make claiming conditional/atomic in Kata, or add a durable claim token/compare-and-set step and verify ownership/claim state before spawning.

Medium

Location: plugins/pi-tasks-kata/src/kata.ts:197
Problem: removeLabel swallows every failure, not just “label is absent”; TaskUpdate status=pending, failed executions, and completions can report success while the in_progress label remains due to a real Kata error.
Fix: Only ignore the specific “label not present” case, and let other label-removal failures propagate; use a separate best-effort cleanup path for rollback.
Location: plugins/pi-tasks-kata/src/subagents.ts:24
Problem: unsubscribe is declared as a const and initialized by events.on, but it is called within the event handler. If events.on fires the callback synchronously, it will throw a ReferenceError for accessing the variable before initialization.
Fix: Declare let unsubscribe: () => void; before the setTimeout, and assign it from events.on.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T17:51:20Z

roborev: Combined Review (`e3ed3af`)

Medium-risk issues found in task execution lifecycle and claim handling; no critical or high findings.

Medium

plugins/pi-tasks-kata/src/index.ts:135
If kata.failExecution() fails while handling a spawn failure, TaskExecute throws out of the loop, skips remaining task IDs, and does not return the collected failure text.
Fix: Wrap failure recording in its own try/catch, log cleanup errors, still append the original task failure, and continue processing the rest of the requested tasks.
plugins/pi-tasks-kata/src/kata.ts:190
removeLabel() suppresses every Kata error, not just “label is absent”; on real CLI/workspace failures, failed executions can leave in_progress on the task while still adding a failure comment, making the task continue to appear active.
Fix: Only ignore the specific absent-label case, or check current labels before removal and let unexpected command failures propagate.
plugins/pi-tasks-kata/src/kata.ts:113
Task claiming is a non-atomic read-then-write sequence, so two concurrent TaskExecute calls can both observe an open task without in_progress and both spawn agents for it.
Fix: Use an atomic Kata claim/conditional update if available, or add a lock/compare-and-set mechanism that makes the label/owner transition fail when another executor has already claimed the task.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T17:56:16Z

roborev: Combined Review (`876b488`)

Medium: rollback can erase pre-existing task ownership during claim failure.

Medium

plugins/pi-tasks-kata/src/kata.ts:142
- Problem: Claim rollback always unassigns the task after a partial claim failure, even if the task had a pre-existing owner before assign() overwrote it. This can silently erase existing ownership metadata on any assigned open task when the later label/comment step fails.
- Fix: Preserve detail.issue.owner before assigning and restore that owner on rollback, or reject execution for tasks already owned by another agent instead of overwriting ownership.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:01:08Z

roborev: Combined Review (`5ddc3be`)

Medium severity findings need attention before merge.

Medium

plugins/pi-tasks-kata/src/index.ts:136
When TaskExecute successfully claims a previously unowned task but subagent spawn fails or times out, cleanup calls failExecution, which only removes in_progress and comments. The task remains assigned to the current author, and claimForExecution rejects other owners, so the task can become stranded for other agents.
Fix: Track whether the claim created the assignment and unassign during spawn-failure cleanup only for newly assigned tasks.
plugins/pi-tasks-kata/src/kata.ts:127
Claiming is a check-then-mutate sequence protected only by an in-memory lock. Two plugin processes can both read the task as open/unowned, then both assign/label/spawn, causing duplicate execution.
Fix: Use a Kata-level atomic claim/compare-and-set operation, or add a durable lock/conditional assignment that fails if owner/status changed before spawning.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:06:56Z

roborev: Combined Review (`8c94fc7`)

Changes need one fix before merge: status updates can leave Kata issues in the wrong open/closed state.

Medium

plugins/pi-tasks-kata/src/kata.ts:89 - TaskUpdate status transitions do not account for the current Kata issue state. Setting status: "in_progress" only adds the label, so a closed issue remains closed and still formats as completed; setting status: "pending" always runs kata reopen, which can fail or create partial updates for already-open tasks. Fetch the current task before status mutations, reopen only when the issue is closed, and reopen before adding in_progress when moving a closed task back into progress.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:12:59Z

roborev: Combined Review (`6f459ae`)

Summary verdict: One medium issue should be addressed before merging.

Medium

Sensitive tool input can be exposed in errors/logs
plugins/pi-tasks-kata/src/kata.ts:303

defaultKataRunner builds failure messages with args.join(" "). Some command paths pass user-controlled or potentially sensitive content in CLI args, especially comment --body values from metadata, activeForm, subagent results, and subagent errors. If kata comment or another mutation fails, the thrown error can include the full comment body, which may then be returned by a tool handler or logged through lifecycle cleanup paths such as plugins/pi-tasks-kata/src/index.ts:127.

Remediation: redact sensitive argument values in runner errors. For example, replace values for --body, --idempotency-key, and similar value-bearing flags with placeholders, or report only the subcommand, exit code, and stderr/stdout. Keep full args available only behind explicit debug behavior that still redacts by default.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:20:22Z

roborev: Combined Review (`1e37f81`)

Summary verdict: Medium-risk issues remain around sensitive output leakage, CLI argument validation, and task ownership enforcement.

Medium

plugins/pi-tasks-kata/src/kata.ts:304
Runner errors redact the command label but still append raw stderr/stdout, which can leak task bodies, metadata, comments, or other sensitive arguments if Kata echoes them in failures.
Fix: Redact or omit child output in thrown errors, or apply the same sensitive-value filtering to stderr/stdout.
plugins/pi-tasks-kata/src/kata.ts:63
Public task IDs and dependency IDs are accepted as arbitrary strings and passed as CLI positionals, so values beginning with - can be parsed as Kata options instead of issue numbers.
Fix: Validate issue IDs as positive integers before constructing CLI args, or use a supported -- separator for positional user values.
plugins/pi-tasks-kata/src/index.ts:86, plugins/pi-tasks-kata/src/kata.ts:78
TaskUpdate can bypass task ownership checks. TaskExecute refuses to claim tasks owned by another agent, but TaskUpdate exposes owner, status, addBlocks, and addBlockedBy without checking the current owner or caller identity. A caller could take ownership, alter status, or close/reopen another agent’s task, then call TaskExecute.
Fix: Enforce the same ownership rules in TaskUpdate before applying mutations. Load the current issue, reject updates to tasks owned by a different agent unless a privileged/admin path exists, and restrict non-owners from changing owner or status.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:26:49Z

roborev: Combined Review (`d4d3fea`)

Summary verdict: Medium-risk lifecycle issues remain; no security findings were reported.

Medium

Location: plugins/pi-tasks-kata/src/kata.ts:338
Problem: defaultKataRunner omits stderr/stdout from thrown errors, but removeLabel() relies on the error text to detect benign “label not found” failures. In real Kata CLI use, completing or resetting a task without in_progress can fail instead of being treated as idempotent.
Fix: Throw a structured/sanitized command error that still exposes stderr for programmatic checks, or return exit metadata so isAbsentLabelError() can inspect the CLI output without leaking secrets.
Location: plugins/pi-tasks-kata/src/kata.ts:216
Problem: completeExecution() removes in_progress before closing the issue. If label removal succeeds but kata close fails, the task is left open and no longer marked in progress, making it appear claimable again after a completed subagent.
Fix: Close the issue first, then remove the label; a closed issue is already rendered as completed even if the label cleanup later fails.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:30:17Z

roborev: Combined Review (`a2040c1`)

High confidence: the PR has two actionable findings, including one High-severity duplicate-claim risk; no Critical findings were reported.

High

plugins/pi-tasks-kata/src/kata.ts:42 - The durable claim lock defaults to process.cwd() or the raw KATA_WORKSPACE value rather than Kata’s resolved project root, so two Pi sessions operating on the same Kata project from different directories can take different locks. Because the claim itself is a non-atomic show/assign/label sequence, both sessions can pass the preflight and spawn duplicate subagents for the same task.
- Fix: Store claim locks under a canonical Kata project/workspace path, or move claiming into an atomic Kata CLI/daemon operation that fails when owner or in_progress changed.

Medium

plugins/pi-tasks-kata/src/format.ts:16 - TaskList renders blockers from issue.blockedBy, but kata list --json returns outgoing blocks, not incoming blockedBy. Blocked tasks therefore appear as ordinary pending tasks in list output even though TaskExecute later refuses to run them.
- Fix: Hydrate incoming blockers from show/links when listing, or extend/normalize Kata list output to include blockedBy.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:33:35Z

roborev: Combined Review (`0bad1d9`)

Medium issue found; no Critical or High findings reported.

Medium

plugins/pi-tasks-kata/src/kata.ts:118 - TaskUpdate status=completed removes the in_progress label before closing the issue, so a failed kata close leaves the task open but no longer marked in progress. Close the issue first, then remove in_progress, or restore the label if close fails.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:39:41Z

roborev: Combined Review (`b54cf18`)

Medium issue found: sanitized Kata command failures may still leak raw stderr/stdout through logged error objects.

Medium

Raw Kata command output can leak to logs

Locations: plugins/pi-tasks-kata/src/kata.ts:321, plugins/pi-tasks-kata/src/kata.ts:351, plugins/pi-tasks-kata/src/index.ts:129, plugins/pi-tasks-kata/src/index.ts:142, plugins/pi-tasks-kata/src/index.ts:203, plugins/pi-tasks-kata/src/index.ts:214

KataCommandError sanitizes the public error message, but still stores raw stderr/stdout on the error object via output. Several catch blocks pass the full error object to console.error, and Node commonly prints enumerable custom properties on Error objects. That can expose sensitive Kata output such as task bodies, comments, subagent results, or command failure context in process or CI logs.

A likely leak path is a subagent completion or failure containing sensitive text, followed by a failed kata comment mutation where Kata echoes the rejected body or context in stderr/stdout. The full KataCommandError can then be logged by lifecycle mutation handling.

Suggested fix: log only sanitized text, such as error instanceof Error ? error.message : String(error). Avoid passing raw Kata command errors directly to console.error. If raw output is still needed for absent-label detection, make it non-enumerable/private or replace it with a sanitized classification signal.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-05T18:44:57Z

roborev: Combined Review (`86fe876`)

Clean overall: no Medium, High, or Critical findings were reported.

All review agents found no actionable issues at Medium severity or above.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-17T18:05:04Z

roborev: Combined Review (`8015921`)

The PR is mostly clean, but there is one Medium concurrency/security issue to address before merge.

Medium

plugins/pi-tasks-kata/src/kata.ts:149, plugins/pi-tasks-kata/src/kata.ts:151, plugins/pi-tasks-kata/src/kata.ts:289
claimForExecution locks using the raw caller-supplied taskId, while the plugin accepts multiple refs for the same Kata task, such as short_id, qualified ref, or ULID. Concurrent TaskExecute calls using different aliases can create different lock names and bypass both the file lock and in-memory claimLocks, allowing multiple executions to pass claim checks before labels are applied.

Impact: duplicate subagents can execute the same task concurrently, causing conflicting mutations and bypassing the intended single-executor lifecycle.

Suggested fix: canonicalize the task before locking and lock on a stable server-derived identifier such as issue.uid or short_id. Re-read issue state after acquiring the canonical lock before assigning, labeling, and spawning. If Kata supports an atomic claim/compare-and-set operation, use that instead.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-21T21:29:18Z

roborev: Combined Review (`8015921`)

Medium issue found: alias-based task claiming can race and allow duplicate execution.

Medium

plugins/pi-tasks-kata/src/kata.ts:144 — claimForExecution locks using the caller-supplied task ref before resolving the issue. Because aliases can refer to the same Kata issue, concurrent TaskExecute calls with different refs can acquire different locks and both pass open/not-in-progress checks before mutation is visible.

Fix: Resolve the issue first under a temporary validation lock, then lock on a canonical server-derived ref such as issue.short_id or issue.uid, re-read the issue, and only then assign/label/spawn. Add a test that races two aliases for the same returned issue.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-26T16:56:33Z

roborev: Combined Review (`2768f04`)

High: plugins/pi-tasks-kata/src/kata.ts:120 calls kata close <ref> --reason done --json for TaskUpdate status=completed and completeExecution without the required close message and evidence, so normal done closes will be rejected by the CLI/daemon. This breaks completed updates and successful TaskExecute lifecycle closure. Supply a substantive --message and accepted --evidence, or route through an API that provides those fields.

Medium: plugins/pi-tasks-kata/src/kata.ts:129 invokes kata block ... for dependency updates, but the CLI has no block subcommand. Relationships are added via kata edit --blocks / --blocked-by, so TaskUpdate with addBlocks or addBlockedBy will fail at runtime. Replace these calls with kata edit <taskId> --blocks <target> --json and kata edit <taskId> --blocked-by <blocker> --json.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-05-26T17:03:10Z

roborev: Combined Review (`ae109f0`)

No Medium, High, or Critical issues found.

All reviewed agents reported the code as clean.

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

roborev-ci · 2026-06-01T18:06:30Z

roborev: Pass

No issues found.

Review type: | Agent: codex | Job: 19210

Kata no longer exposes stable per-project issue numbers after the short_id cutover, so the pi task adapter must treat task ids as Kata refs instead of integers. Without this, created tasks could not record metadata and execution/update flows passed legacy numeric identifiers back to the CLI. Keep legacy number fallback only for old fixtures, but prefer short_id/qualified refs in displays, dependency resolution, locks, lifecycle logging, and user-facing tool descriptions. Validation: GOFLAGS=-buildvcs=false go test ./... && cd plugins/pi-tasks-kata && npm test -- --run && npm run typecheck && npm run build Generated with Pi Co-authored-by: Pi <pi@users.noreply.github.com>

Task execution accepts multiple Kata refs for the same issue, but claim locking previously used the caller-supplied ref directly. That left alias pairs such as a short id and qualified ref able to take separate in-process and durable locks before either mutation made the task visibly in progress. Resolve the issue first, then claim under a stable server-derived ref and re-read inside that canonical lock before assigning, labeling, or spawning. This keeps the existing rollback behavior while closing the duplicate-execution race. Validation: cd plugins/pi-tasks-kata && npm test && npm run typecheck && npm run build Generated with Codex Co-authored-by: Codex <codex@openai.com>

Kata close now requires done closes to carry substantive closure metadata, and relationship updates are edited through the issue mutation command rather than the retired block subcommand. The adapter needs to follow that CLI contract or TaskUpdate and TaskExecute lifecycle paths fail at runtime despite passing earlier unit-level assumptions. Use the current close flags with task-specific messages and typed evidence, and route dependency additions through kata edit relationship flags so the plugin exercises the shipped command surface. Validation: cd plugins/pi-tasks-kata && npm test && npm run typecheck && npm run build Generated with Codex Co-authored-by: Codex <codex@openai.com>

main removed docs/superpowers/ and adopted a fold-then-remove policy for planning specs (#77): once work ships, durable rationale moves into maintained docs so stale drafts do not compete with them. After rebasing onto main, this branch was the only thing re-creating that directory, and its spec had already drifted from the implementation (it still described numeric issue ids). Keep the durable design decisions — short_id task identity, the open/in_progress/closed status mapping, metadata-as-comments, and the fake-runner test seam — in the plugin README, and drop the spec and plan. Validation: cd plugins/pi-tasks-kata && npm test && npx tsc --noEmit Generated with Claude Code (claude-fable-5) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

roborev-ci · 2026-06-12T03:00:02Z

roborev: Combined Review (`c4a67bc`)

Medium severity findings:

plugins/pi-tasks-kata/src/kata.ts:81 - Dependency ref preflight only rejects empty, option-like, and short numeric refs, so invalid refs such as kata#12 or bad! can pass validation. updateTask can then apply earlier mutations like title/status before a later kata edit --blocks/--blocked-by command fails, leaving a partial update despite the intended all-refs-before-mutation guard. Validate dependency refs with the same accepted syntax as Kata refs, or resolve all dependency refs with a non-mutating command before applying any update mutation.
plugins/pi-tasks-kata/src/kata.ts:206 - Claiming ignores whether kata label add ... in_progress actually changed the issue. If another executor marks the task in_progress after the preflight show but before this label add, Kata returns a no-op mutation, and this code still records a claim and spawns a second subagent for the same task. Have addLabel return the mutation envelope and abort or roll back when adding in_progress returns changed: false, or use an atomic server-side claim/lease mechanism.
plugins/pi-tasks-kata/src/format.ts:18, plugins/pi-tasks-kata/src/format.ts:34, plugins/pi-tasks-kata/src/format.ts:38, plugins/pi-tasks-kata/src/format.ts:45 - Kata task titles, bodies, owners, authors, labels, and comments are interpolated directly into Pi text results. A malicious issue/comment can include ANSI, OSC, or control sequences that may spoof output, hide text, set terminal hyperlinks/window title, or trigger terminal features such as clipboard writes in supporting terminals. Sanitize at the plugin’s human-facing text boundary before building textResult, including tests with CSI/OSC escape sequences.

Panel: ci_default_security | Synthesis: codex, 12s | Members: codex_default (codex/default, done, 4m57s), codex_security (codex/security, done, 4m47s) | Total: 9m56s

Three review findings shared a root cause: the plugin trusted that its preflight checks and the daemon's raw JSON were enough. Dependency refs were only syntax-checked, so an unresolvable ref failed at the kata edit step after title/status mutations had already applied, defeating the all-refs-before-mutation guard. Each ref is now resolved with a non-mutating show before anything mutates. A claim could double-execute: between the preflight show and the in_progress label add, another executor could win the race, and the daemon reports that as a changed:false no-op rather than an error. The claim now aborts on a no-op label add, rolling back ownership but leaving the other claimant's label alone. kata --json deliberately returns raw daemon bytes (sanitization is the terminal renderer's job, per internal/textsafe), so the plugin now strips ANSI CSI/OSC escapes and control/format runes from server-sourced titles, bodies, owners, labels, and comments at its human-facing text boundary, and keeps single-row fields from injecting forged lines. Validation: cd plugins/pi-tasks-kata && npm test && npx tsc --noEmit && npm run build Generated with Claude Code (claude-fable-5) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

roborev-ci · 2026-06-12T11:35:49Z

roborev: Combined Review (`bf19db0`)

PR review verdict: changes need fixes before merge due to one high-risk cross-project mutation bug and one partial-update bug.

High

plugins/pi-tasks-kata/src/kata.ts:180: TaskExecute canonicalizes any ref to short_id, so executing a qualified ref like other#ab12 drops the project qualifier and then claims/mutates bare ab12 in the current workspace. If the same short ID exists locally, the wrong task can be assigned, labeled, spawned, and closed.
- Fix: Keep the caller’s resolved command ref for all Kata CLI mutations and use a separate UID-based key only for locking; add a test covering qualified refs from a non-current project.

Medium

plugins/pi-tasks-kata/src/kata.ts:140: status: "deleted" is rejected only after title/body/owner edits have already been applied, so an unsupported delete update can still partially mutate the task before returning an error.
- Fix: Reject status === "deleted" before building or running any mutation commands, and cover the mixed deleted-plus-details case.

Panel: ci_default_security | Synthesis: codex, 9s | Members: codex_default (codex/default, done, 6m48s), codex_security (codex/security, done, 2m32s) | Total: 9m29s

mariusvniekerk marked this pull request as draft May 5, 2026 17:35

mariusvniekerk force-pushed the pi-tasks-kata-plugin branch from 86fe876 to 8015921 Compare May 17, 2026 18:02

mariusvniekerk added 10 commits June 11, 2026 22:49

feat: add kata-backed pi tasks plugin

a79347d

fix: harden pi task subagent lifecycle

617f793

fix: guard kata task execution claims

3d8caf7

fix: preserve claim rollback cleanup

8c122c4

fix: keep rollback errors isolated

85467e4

fix: harden kata task execution lifecycle

db4e2ce

fix: preserve kata task ownership on claim rollback

f9f561b

fix: lock kata task claims during execution spawn

8587ccc

fix: respect kata issue state in task updates

73145b9

fix: redact kata runner error commands

1ac3e75

mariusvniekerk and others added 9 commits June 11, 2026 22:49

fix: harden kata task input boundaries

5d4671e

fix: preflight kata dependency ids

2a3e2cc

fix: preserve sanitized kata error metadata

a15c4ed

fix: close task updates before label cleanup

8e5599f

fix: sanitize kata error logging

53e1508

mariusvniekerk force-pushed the pi-tasks-kata-plugin branch from ae109f0 to c4a67bc Compare June 12, 2026 02:54

Conversation

mariusvniekerk commented May 5, 2026

Summary

Validation

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (d7e277e)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (ad6352e)

High

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (e3ed3af)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (876b488)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (5ddc3be)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (8c94fc7)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (6f459ae)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (1e37f81)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (d4d3fea)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (a2040c1)

High

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (0bad1d9)

Medium

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (b54cf18)

Medium

Raw Kata command output can leak to logs

Uh oh!

roborev-ci Bot commented May 5, 2026

roborev: Combined Review (86fe876)

Uh oh!

roborev-ci Bot commented May 17, 2026

roborev: Combined Review (8015921)

Medium

Uh oh!

roborev-ci Bot commented May 21, 2026

roborev: Combined Review (8015921)

Medium

Uh oh!

roborev-ci Bot commented May 26, 2026

roborev: Combined Review (2768f04)

Uh oh!

roborev-ci Bot commented May 26, 2026

roborev: Combined Review (ae109f0)

Uh oh!

roborev-ci Bot commented Jun 1, 2026

roborev: Pass

Uh oh!

roborev-ci Bot commented Jun 12, 2026

roborev: Combined Review (c4a67bc)

Uh oh!

roborev-ci Bot commented Jun 12, 2026

roborev: Combined Review (`d7e277e`)

roborev: Combined Review (`ad6352e`)

roborev: Combined Review (`e3ed3af`)

roborev: Combined Review (`876b488`)

roborev: Combined Review (`5ddc3be`)

roborev: Combined Review (`8c94fc7`)

roborev: Combined Review (`6f459ae`)

roborev: Combined Review (`1e37f81`)

roborev: Combined Review (`d4d3fea`)

roborev: Combined Review (`a2040c1`)

roborev: Combined Review (`0bad1d9`)

roborev: Combined Review (`b54cf18`)

roborev: Combined Review (`86fe876`)

roborev: Combined Review (`8015921`)

roborev: Combined Review (`8015921`)

roborev: Combined Review (`2768f04`)

roborev: Combined Review (`ae109f0`)

roborev: Combined Review (`c4a67bc`)

roborev: Combined Review (`bf19db0`)