ci: add consolidated CodeBuild buildspec for lint+test (#265)

* ci: add consolidated CodeBuild buildspec for lint+test

Adds ci/buildspecs/ci.yml — a single buildspec that runs lint + test for
every component (cli, server, plugin, schema, sdk-go, sdk-python,
install, licenses, prompts-sync) in sequence. This is the CodeBuild
replacement for the nine .github/workflows/ci-*.yaml workflows, run by
the new consolidated CodeBuild project `8th-layer-agent-ci`.

One pass/fail PR check instead of nine. Granular per-component splitting
is deliberately out of scope for a fork this size — on failure the build
log names the failing component.

Toolchains are installed explicitly in the install phase so the build is
reproducible regardless of the base image: Go 1.26.1 (all go.mod files
pin it, newer than amazonlinux-standard:5.0 ships), golangci-lint
v2.10.1, uv, and Node 22 + pnpm 10.

The 9 ci-*.yaml workflows are removed in a follow-up PR once a green
CodeBuild run confirms parity.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* ci: quote buildspec command scalars to fix YAML parse error

CodeBuild's buildspec YAML parser rejected the first build with
"did not find expected key at line 65" — the `echo "::: [component] ..."`
log markers start with a colon, which an unquoted YAML scalar reads as a
mapping key. Single-quote every command list item so each is an
unambiguous scalar, and drop the in-sequence divider comments (the echo
markers already label each component).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* chore: sync SDK prompt copies with canonical plugin sources

The first consolidated CodeBuild CI run surfaced pre-existing drift:
`sdk/go/prompts/{SKILL,reflect}.md` and `sdk/python/src/cq/prompts/{SKILL,reflect}.md`
were out of sync with their canonical sources under `plugins/cq/`.

The plugin sources document the `propose_batch` reflect flow but the SDK
copies still described the older per-candidate `propose` flow — the
`propose_batch` change updated the plugin without re-running
`make sync-prompts` in the SDKs. The GHA `ci-prompts-sync.yaml` only
fires on paths touching these files, so the drift slipped through.

Ran `make sync-prompts` to bring all four copies back in line. This
unblocks the consolidated CI build's first check (`check-prompts-sync`).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: David Winter <dw@choruscap.ai>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: 3 people

ci/buildspecs/ci.yml

@@ -0,0 +1,107 @@
+version: 0.2
+
+# Consolidated CI for 8th-layer-agent — runs lint + test for every
+# component in one CodeBuild project (`8th-layer-agent-ci`,
+# account 124074140789, us-east-1). One pass/fail PR check.
+#
+# This replaces the nine `.github/workflows/ci-*.yaml` GitHub Actions
+# workflows (ci-cli, ci-install, ci-licenses, ci-plugin, ci-prompts-sync,
+# ci-schema, ci-sdk-go, ci-sdk-python, ci-server). Granular 9-way
+# splitting is deliberately out of scope — for a fork this size one
+# consolidated check is simpler to operate. If a check fails, the build
+# log names the failing component.
+#
+# Triggers (PR events + push to main) are encoded on the CodeBuild
+# project webhook FilterGroups, not here.
+#
+# Toolchains installed explicitly so the build is reproducible regardless
+# of the base image:
+#   - Go 1.26.1   — cli/go.mod, schema/go.mod, sdk/go/go.mod all pin
+#                   1.26.1, newer than the amazonlinux-standard:5.0 image
+#                   ships. Same curl-tarball pattern as cli-release.yml.
+#   - golangci-lint v2.10.1 — pinned to match the GHA golangci-lint-action.
+#   - uv          — Python toolchain (astral-sh/setup-uv@v7 analog).
+#   - Node 22 + pnpm 10 — server frontend (setup-node + pnpm/action-setup).
+#
+# `set -e` is in effect for every build command (CodeBuild default), so a
+# failing check fails the build. Components run in sequence; the first
+# failure aborts the build and the rest are skipped — the log shows which
+# component failed.
+
+env:
+  variables:
+    GO_VERSION: "1.26.1"
+    GOLANGCI_LINT_VERSION: "v2.10.1"
+    NODE_VERSION: "22"
+    PNPM_VERSION: "10"
+    UV_NO_PROGRESS: "1"
+    UV_CACHE_DIR: /codebuild/output/.uv-cache
+
+phases:
+  install:
+    commands:
+      - 'echo "=== Installing Go ${GO_VERSION} ==="'
+      - 'curl -fsSL "https://go.dev/dl/go${GO_VERSION}.linux-amd64.tar.gz" | tar -C /usr/local -xz'
+      - 'export PATH="/usr/local/go/bin:$(go env GOPATH 2>/dev/null || echo $HOME/go)/bin:${PATH}"'
+      - 'go version'
+      - 'echo "=== Installing golangci-lint ${GOLANGCI_LINT_VERSION} ==="'
+      - 'curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b /usr/local/bin "${GOLANGCI_LINT_VERSION}"'
+      - 'golangci-lint --version'
+      - 'echo "=== Installing uv (astral-sh/setup-uv@v7 analog) ==="'
+      - 'curl -LsSf https://astral.sh/uv/install.sh | sh'
+      - 'export PATH="$HOME/.local/bin:${PATH}"'
+      - 'uv --version'
+      - 'echo "=== Installing Node ${NODE_VERSION} + pnpm ${PNPM_VERSION} ==="'
+      - 'n ${NODE_VERSION} || (curl -fsSL https://raw.githubusercontent.com/tj/n/master/bin/n | bash -s ${NODE_VERSION})'
+      - 'node --version'
+      - 'corepack enable'
+      - 'corepack prepare "pnpm@${PNPM_VERSION}" --activate'
+      - 'pnpm --version'
+
+  build:
+    commands:
+      - 'export PATH="/usr/local/go/bin:$(go env GOPATH 2>/dev/null || echo $HOME/go)/bin:$HOME/.local/bin:${PATH}"'
+      - 'echo "::: [prompts-sync] verifying SDK prompt copies match plugin sources"'
+      - 'make check-prompts-sync'
+      - 'echo "::: [schema] validate JSON Schema fixtures + values"'
+      - 'make validate-schema'
+      - 'echo "::: [schema] lint + test (Go module + Python package)"'
+      - 'make setup-schema'
+      - 'make lint-schema'
+      - 'make test-schema'
+      - 'echo "::: [cli] setup + lint (golangci-lint, check-licenses, check-notice)"'
+      - 'make setup-cli'
+      - 'make lint-cli'
+      - 'echo "::: [cli] test + build"'
+      - 'make test-cli'
+      - '(cd cli && make build)'
+      - 'echo "::: [sdk-go] setup + lint (prompts-sync, golangci-lint, licenses, notice)"'
+      - 'make setup-sdk-go'
+      - 'make lint-sdk-go'
+      - 'echo "::: [sdk-go] test"'
+      - 'make test-sdk-go'
+      - 'echo "::: [licenses] covered by lint-cli + lint-sdk-go (check-licenses/check-notice)"'
+      - 'echo "::: [plugin] setup + lint"'
+      - 'make setup-plugin'
+      - 'make lint-plugin'
+      - 'echo "::: [plugin] test (Cursor hook helper)"'
+      - 'make test-plugin'
+      - 'echo "::: [install] setup + lint + test (installer + plugin hook)"'
+      - 'make setup-install'
+      - 'make lint-install'
+      - 'make test-install'
+      - 'echo "::: [sdk-python] setup + lint + test"'
+      - 'make setup-sdk-python'
+      - 'make lint-sdk-python'
+      - 'make test-sdk-python'
+      - 'echo "::: [server] setup + lint + test (backend + frontend)"'
+      - 'make setup-server'
+      - 'make lint-server'
+      - 'make test-server'
+      - 'echo "=== All CI checks passed ==="'
+cache:
+  paths:
+    - '/codebuild/output/.uv-cache/**/*'
+    - '/root/.cache/uv/**/*'
+    - '/root/.cache/go-build/**/*'
+    - '/root/go/pkg/mod/**/*'

sdk/go/prompts/SKILL.md

@@ -169,7 +169,7 @@ If no coherent lesson survives sanitization across all affected fields, the cand
 #### Applying VIBE√
 
 - **Direct `propose` calls** (outside `/cq:reflect`) — run the check on the single candidate. If a hard finding exists, present both the original and the sanitized rewrite to the user and let them pick (or skip). If only a soft concern exists, present the concern for awareness before proceeding.
-- **Batch proposals via `/cq:reflect`** — see the `/cq:reflect` command for the batch presentation UX (three templates, provenance annotation). The underlying V/I/B/E classification rules are the same.
+- **Batch proposals via `/cq:reflect`** — clean and soft candidates are sent in a single `propose_batch` call to keep the harness's tool-output noise bounded; hard findings still go through per-candidate `propose` after inline review. See the `/cq:reflect` command for the full batch presentation UX (three templates, provenance annotation). The underlying V/I/B/E classification rules are the same.
 
 ### Confirming Knowledge (`confirm`)
 

sdk/go/prompts/reflect.md

@@ -75,7 +75,33 @@ If a hard finding cannot be coherently sanitized, the candidate fails Step 2's g
 
 #### Auto-propose phase (Step 3a — silent)
 
-For each candidate classified as `clean` or `soft` in Step 2.5, call `propose` immediately without presenting. Soft concerns are not lost — they are listed in the Step 6 final summary so the operator can see what flags were raised.
+Collect every candidate classified as `clean` or `soft` in Step 2.5 into a single list, then call **`propose_batch`** ONCE with that list. The `propose_batch` tool stores all candidates in one MCP round-trip and returns one combined response, capping the harness's tool-call echo at a single tool invocation regardless of candidate count.
+
+```
+propose_batch(
+  candidates=[
+    {summary: ..., detail: ..., action: ..., domains: [...], languages?, frameworks?, pattern?},
+    ...
+  ]
+)
+```
+
+Use the per-candidate `propose` tool only for hard findings (Step 5), where each candidate needs human judgment and earns its own tool call.
+
+The batch response shape:
+
+```json
+{
+  "stored": [{"index": 0, "id": "ku_...", "summary": "...", "tier": "private"}, ...],
+  "errors": [{"index": 2, "summary": "...", "error": "..."}]
+}
+```
+
+`index` is the candidate's original position in the input list. Carry the `clean`/`soft` classification per index from Step 2.5 so Step 6 can render the correct provenance annotation against each stored ID.
+
+If `candidates` is empty (no clean or soft candidates this session), skip the `propose_batch` call entirely.
+
+Soft concerns are not lost — they are listed in the Step 6 final summary so the operator can see what flags were raised.
 
 Do NOT auto-propose hard findings, even with sanitization. Hard findings always require human judgment because the sanitized rewrite may have stripped content the operator cares about, or the operator may want to escalate the finding rather than store either form.
 
@@ -186,6 +212,15 @@ IDs stored this session:
 
 Always show the `{total} candidates identified.` line. Omit any line whose count is zero. Omit any VIBE√ findings bullet whose category has no entries.
 
+Render the `IDs stored this session` list by combining the `propose_batch` response (auto-stored clean+soft candidates) with the per-candidate `propose` results from Step 5 (hard findings). For each entry in the batch response's `stored` array, look up the original `clean` or `soft` classification by `index` and use it as the bracketed annotation. If the batch response includes any `errors` entries, list them as a final bullet:
+
+```
+Errors during batch store:
+- index {n} ("{summary}"): {error}
+```
+
+Errors do not block the summary — surface them so the operator knows which candidates fell out, then move on.
+
 The bracketed annotation on each stored ID records the VIBE√ provenance of what was stored:
 
 - `clean` — no VIBE√ findings; auto-stored without prompting.

sdk/python/src/cq/prompts/SKILL.md

@@ -169,7 +169,7 @@ If no coherent lesson survives sanitization across all affected fields, the cand
 #### Applying VIBE√
 
 - **Direct `propose` calls** (outside `/cq:reflect`) — run the check on the single candidate. If a hard finding exists, present both the original and the sanitized rewrite to the user and let them pick (or skip). If only a soft concern exists, present the concern for awareness before proceeding.
-- **Batch proposals via `/cq:reflect`** — see the `/cq:reflect` command for the batch presentation UX (three templates, provenance annotation). The underlying V/I/B/E classification rules are the same.
+- **Batch proposals via `/cq:reflect`** — clean and soft candidates are sent in a single `propose_batch` call to keep the harness's tool-output noise bounded; hard findings still go through per-candidate `propose` after inline review. See the `/cq:reflect` command for the full batch presentation UX (three templates, provenance annotation). The underlying V/I/B/E classification rules are the same.
 
 ### Confirming Knowledge (`confirm`)
 

sdk/python/src/cq/prompts/reflect.md

@@ -75,7 +75,33 @@ If a hard finding cannot be coherently sanitized, the candidate fails Step 2's g
 
 #### Auto-propose phase (Step 3a — silent)
 
-For each candidate classified as `clean` or `soft` in Step 2.5, call `propose` immediately without presenting. Soft concerns are not lost — they are listed in the Step 6 final summary so the operator can see what flags were raised.
+Collect every candidate classified as `clean` or `soft` in Step 2.5 into a single list, then call **`propose_batch`** ONCE with that list. The `propose_batch` tool stores all candidates in one MCP round-trip and returns one combined response, capping the harness's tool-call echo at a single tool invocation regardless of candidate count.
+
+```
+propose_batch(
+  candidates=[
+    {summary: ..., detail: ..., action: ..., domains: [...], languages?, frameworks?, pattern?},
+    ...
+  ]
+)
+```
+
+Use the per-candidate `propose` tool only for hard findings (Step 5), where each candidate needs human judgment and earns its own tool call.
+
+The batch response shape:
+
+```json
+{
+  "stored": [{"index": 0, "id": "ku_...", "summary": "...", "tier": "private"}, ...],
+  "errors": [{"index": 2, "summary": "...", "error": "..."}]
+}
+```
+
+`index` is the candidate's original position in the input list. Carry the `clean`/`soft` classification per index from Step 2.5 so Step 6 can render the correct provenance annotation against each stored ID.
+
+If `candidates` is empty (no clean or soft candidates this session), skip the `propose_batch` call entirely.
+
+Soft concerns are not lost — they are listed in the Step 6 final summary so the operator can see what flags were raised.
 
 Do NOT auto-propose hard findings, even with sanitization. Hard findings always require human judgment because the sanitized rewrite may have stripped content the operator cares about, or the operator may want to escalate the finding rather than store either form.
 
@@ -186,6 +212,15 @@ IDs stored this session:
 
 Always show the `{total} candidates identified.` line. Omit any line whose count is zero. Omit any VIBE√ findings bullet whose category has no entries.
 
+Render the `IDs stored this session` list by combining the `propose_batch` response (auto-stored clean+soft candidates) with the per-candidate `propose` results from Step 5 (hard findings). For each entry in the batch response's `stored` array, look up the original `clean` or `soft` classification by `index` and use it as the bracketed annotation. If the batch response includes any `errors` entries, list them as a final bullet:
+
+```
+Errors during batch store:
+- index {n} ("{summary}"): {error}
+```
+
+Errors do not block the summary — surface them so the operator knows which candidates fell out, then move on.
+
 The bracketed annotation on each stored ID records the VIBE√ provenance of what was stored:
 
 - `clean` — no VIBE√ findings; auto-stored without prompting.