Repository navigation
chore(055.W4.2): allowed-tools + capability analyzer (merge-back) - #1
Conversation
… DERIVED by static analysis
D17 + D20(4). Delivers VISIBILITY, not containment: nothing here sandboxes a plugin. Real
containment needs an execution host, and the ADR rejects a third-party WASM host with evidence
("o Zed provou que mesmo com wasmtime completo a extensão não desenha UI"). v1 warns and
displays; the blocking path exists in code, off by configuration, trigger documented ("when
opening to externals").
AC1 — `allowed-tools` is MANDATORY on every publishable skill, unconditionally blocking at
publish. Refuses the absent field, the empty value, the `*` wildcard, and the snake/camelCase
spellings the runtime would silently ignore. Accepts all three canonical value shapes
(comma string, space string, YAML list).
AC3 — capabilities are DERIVED on the AIOX side from the artifact's own bytes, and the publisher
has NO field in which to assert its own. Enforced as a REFUSAL (`capabilities`, `permissions`,
`grants`, `sandbox`, `trust_level`), never as a silently-ignored field. The entry block carries
`self_declared: false` as data, re-checked in `validateEntryShape`.
AC4 — TWO INDEPENDENT SIGNALS per skill, never collapsed into one number: OWNS_SCRIPTS (hosts
code) and INSTRUCTS_EXECUTION (runs code — own / other-skill / repo / ambient). Measured over the
product repo's 35 SOT skills: 6 and 9. The naive regex everyone quoted also returns 9, but a
DIFFERENT set — it falsely includes `self-heal` and falsely excludes `criar-sot`; two opposite
errors that cancelled in the total. `self-heal` is the mandatory negative fixture and is asserted
to be in NEITHER signal: its only match is prose citing sync.mjs by analogy, and marking it would
reproduce inside the analyzer the calibration error D17 exists to correct.
AC5 — the report states what it CANNOT see, and the limits travel WITH the capabilities onto the
entry and into the rendered catalog: an MCP server is a runtime-resolved {command, args} pointer
(mcp.rs:68) whose `npx` target is never inspected. A capability list shown without its blind
spots lies by omission, so the schema requires `limits` to be non-empty.
AC6 — the derived analysis is rendered on the catalog entry the user reads before installing.
REUSE, not recreation: extends 055.W3.1/W3.3 scaffolding (shared lib/, publish-time + CI gates,
shell out to system `tar` as license-check.mjs does, zero new dependencies). Pre-existing fixtures
updated to carry `allowed-tools` so each negative fixture still fails for EXACTLY its own reason.
151 tests pass (was 147 before the 4 new CLI-level ones); ci.yml gains ONE additive step.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…omentário do fixture negativo
Comentário apenas. Zero comportamento: nenhuma asserção, nenhum código e nenhum dado de teste
mudou — só o `file:line` dentro de um comentário. 151/151 testes seguem passando.
`.aiox-core/skills/self-heal/SKILL.md:31` → `:32`. O TEXTO citado sempre esteve verbatim correto
("Adapters mirror the `sync.mjs` ADAPTERS pattern"); só o número da linha estava um a menos.
Causa raiz (vale mais que o conserto): a citação foi capturada ANTES de a story 055.W4.2 inserir
a linha `allowed-tools` no frontmatter da própria skill, o que empurrou todo o corpo uma linha
para baixo. É erro SISTEMÁTICO, não digitação — atinge toda citação de linha de corpo capturada
antes de uma edição de frontmatter no mesmo arquivo. Re-verificado contra o arquivo real antes de
escrever (linha 31 é vazia; 32 é a linha citada).
`mcp.rs:68`, repetido em 3 lugares deste repo, foi verificado na mesma passada e está CORRETO
(`let entry = json!({ "command": core_bin, "args": ["mcp"] });`) — não herdado por confiança.
Nada mais tocado: `ci.yml` intocado, `index/index.json` segue `{"entries": []}`, sem push.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 30 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (13)
Comment |
1 participant
Merge-back automatizado da story 055.W4.2 (analisador de capabilities + CI aditiva). Ver PR irmã no aiox-cockpit.