docs: CI gate entry point, acs CLI reference, and two missing target rungs

[Chang Liu (changliu2)]

Summary

Adds a CI-gating entry point to the docs, documents the missing acs command group, and closes two gaps in the target decision tree that the CI onboarding skill depends on.

Motivation

The README had no path from "my eval passes locally" to "this blocks bad PRs". Separately, two things the docs said (or omitted) were actively misleading for anyone wiring up a target.

Changes

CI entry point — a short README section pointing at the Action and the coding-agent bootstrap URL, plus a brief docs/ci/README.md that links out rather than duplicating the Action's docs.

docs/cli/commands.md: document the acs group. acs generate, acs validate, and acs eval-config were documented only in docs/guides/securing-agents-with-acs.md and were absent from the CLI reference. Flags were verified against assert_ai/cli.py, not just the guide.

docs/targets/README.md: two missing rungs.

• Bring-your-own OTel traces. A repo that already emits spans can score offline with assert-ai judge-traces --traces <path> --config <path>. This only appeared in the CLI reference, never in the decision tree. Now stated explicitly, including that there is no --trace flag on assert-ai run — a natural assumption that is wrong.
• Black-box HTTP. An earlier revision of this branch claimed ASSERT has no native HTTP target and told users to hand-write a requests shim. That was wrong: target.endpoint exists and is fully implemented (config.py, config_model.py, security.py). The runtime POSTs {"message": ..., "history": [...]} and reads {"response": ...}. target.endpoint is now the documented black-box path; the callable shim is re-scoped to its real use — a service whose request/response shape differs.

run-assert-eval skill: CI hand-off + the corrected HTTP guidance, applied identically across all three front-doors (.claude/skills/, .github/prompts/, .cursor/rules/). Minimal additive edits — the skill's logic, structure, and voice are unchanged. It keeps owning running and reporting; the wire-assert-ci skill owns CI wiring.

Where the Action lives

Links here point at changliu2/assert-ai-action (public, v1 tagged, CI green).

The original responsibleai/assert-action was archived on Jul 14 and is read-only. Neither I nor the repo owner has admin to unarchive it, and pushes to newly created responsibleai/* repos are also denied, so the Action could not be hosted in the org. It is fully transferable once someone with org rights can accept it:

gh api -X POST repos/changliu2/assert-ai-action/transfer -f new_owner=responsibleai

Follow-up after any transfer: re-point the URLs in this PR for clarity. An earlier revision of this description claimed raw.githubusercontent.com does not follow repo-transfer redirects — that was wrong, and I have since tested it directly. After transferring the companion demo repo into the org, the old-owner raw URL still returned HTTP 200 with num_redirects=0 on a cache-busted, never-before-fetched query string, while a nonexistent path 404'd identically under both owner names — so raw is resolving the transferred repo, not serving a stale cache. A transfer will not silently break the bootstrap URL. GitHub does not document this as a guarantee, so the URLs should still be re-pointed after a move, but it is not a blocking risk for merging this PR.

Bootstrap URL verified live (HTTP 200):

https://raw.githubusercontent.com/changliu2/assert-ai-action/main/ONBOARD.md

Discrepancy found

assert_ai/cli.py supports --require-block on acs generate, but docs/guides/securing-agents-with-acs.md omits it. The CLI reference documents the code's actual behaviour. The guide is left alone here but is now known to be incomplete.

Testing

• All YAML frontmatter parses (PyYAML)
• Every relative link added resolves to a real file
• Every external URL added returns HTTP 200
• The three skill front-doors were diffed to confirm the additions are substantively identical
• Diff touches only docs and skill markdown — no source, pyproject.toml, workflows, or viewer changes

[tangym]

The ownership split looks clear: run-assert-eval owns local evaluation, wire-assert-ci generates the repository integration, and the published Action owns deterministic baseline comparison and CI enforcement. Agent-assisted setup also makes sense as the preferred path, with direct workflow authoring available for advanced users.

One concern is that run-assert-eval could drift between ASSERT core and the Action repo. Could we either npx install the two canonical skills from their respective repos, or mechanically sync the Action repo’s copy from ASSERT with a CI freshness check?

[Chang Liu (changliu2)]

Ran an independent source-verification pass on this PR (checked claims against assert_ai/cli.py, core/config_model.py, core/session.py, and the actual workflow/action repos rather than trusting the prose). 14 of 17 checked claims held up exactly; fixed the 3 that didn't:

1. Blocking — judge-traces does not score traces. The decision-tree rung and paths table claimed it "scores" a pre-collected trace file. It doesn't — it parses OTel spans into inference_set.jsonl and tells the caller to separately run --force-stage judge. Verified live against tests/fixtures/sample_otel_traces.json: output dir has inference_set.jsonl only, no scores.jsonl. Fixed all three references (decision table, offline-path section, paths-at-a-glance table) to state the real two-step path.
2. assert-ai[aiohttp] is not a real extra — not in pyproject.toml, not on PyPI. Works today only because litellm pulls aiohttp in transitively. Dropped the fake extra from both skill front-doors, replaced with a note that it ships transitively already.
3. New acs CLI reference didn't mention the acs extra, which isn't published on PyPI yet (only via editable repo install). Added a one-line note.

Also registered the new docs/ci/README.md in docs/README.md's index so it's reachable from the docs landing page.

Verified tests/test_framework_agnostic.py -k JudgeTraces still passes (2/2) — confirms the corrected wording matches actual command behavior.