Add Mergify config for automated merge queue by ktdreyer · Pull Request #860 · ambient-code/platform

ktdreyer · 2026-03-09T21:08:50Z

Summary

Adds .mergify.yml with a merge queue that rebases queued PRs onto main and re-runs CI, then squash-merges once all checks pass
PRs enter the queue once they have at least one approved review and no outstanding change requests, satisfying CODEOWNERS requirements

Fixes #858

Prerequisites

The Mergify GitHub App must be installed on the org (Gage completed this today)

Test plan

Validate YAML syntax: python3 -c "import yaml; yaml.safe_load(open('.mergify.yml'))"
After merge, confirm Mergify bot activates on the repo
Open a test PR to verify queue behavior

github-actions · 2026-03-09T21:12:48Z

test

github-actions · 2026-03-09T21:13:35Z

Claude Code Review

Summary

This PR adds a .mergify.yml configuration file (10 lines) to automate the merge queue process. The change is small and well-intentioned, but has two notable issues: the merge method conflicts with the project documented convention, and there are no CI status check requirements to gate automatic merges.

Issues by Severity

Blocker Issues: None

Critical Issues: None

Major Issues

merge_method rebase conflicts with documented squash-merge convention

File: .mergify.yml line 3
Problem: CLAUDE.md explicitly states Conventional commits: Squashed on merge to main. Using merge_method rebase will push each individual commit from a PR onto main rather than squashing them into a single commit. This breaks the linear, single-commit-per-PR history the project has established.
Standard violated: CLAUDE.md - Conventional commits: Squashed on merge to main
Suggested fix: Change merge_method to squash in queue_rules.

No CI status check requirements in queue_rules

File: .mergify.yml lines 1-4
Problem: The queue_rules.default has no conditions, meaning once a PR is enqueued it can be merged without any CI checks passing. If the repo does not have required status checks configured at the GitHub branch protection level, a PR with 1 approval and a failing build or lint run could be automatically merged to main.
Standard violated: General quality gate - CI must pass before merge to main
Suggested fix: Add conditions for the required CI checks (replace job names with your actual GitHub Actions job names): add check-success conditions for lint and test jobs.

Minor Issues

Single approval threshold may be insufficient without CODEOWNERS enforcement

File: .mergify.yml line 8
Problem: The condition approved-reviews-by>=1 only requires one approval from any user. The PR description notes that Require review from Code Owners must be enabled in branch protection, but this is a prerequisite external to this file. If that branch protection rule is ever inadvertently disabled, Mergify would allow any single approval to trigger a merge without CODEOWNERS sign-off.
Suggested enhancement: Consider adding an explicit CODEOWNERS-aware condition to make the config self-documenting and more resilient to branch protection misconfiguration.

Positive Highlights

Clean, minimal configuration with no unnecessary complexity.
Choosing a merge queue (over simple auto-merge) is the right approach for a shared platform repo; it prevents merge races and ensures a controlled merge order.
The PR description clearly lists prerequisites and a test plan, including YAML syntax validation.
The PR links back to the tracking issue 858, making the change fully traceable.

Recommendations

Change merge_method from rebase to squash to align with the documented commit convention in CLAUDE.md. This is the highest-priority fix.
Add CI status check conditions to queue_rules so Mergify cannot merge a PR with broken builds or failing tests. Coordinate with CI maintainers to confirm the exact job names.
Consider documenting the expected branch protection settings (CODEOWNERS enforcement, required checks) in CLAUDE.md or a contributing guide so the prerequisites are not buried in a PR description.

Review generated by Claude Code using repository standards from .claude/context/ and .claude/patterns/

github-actions · 2026-03-09T21:21:16Z

Claude Code Review - See full review below (posted in sections due to formatting constraints)

github-actions · 2026-03-09T21:21:30Z

This is a test with a URL: https://github.com/ambient-code/platform and some backticks like merge_method: squash and some review content.

github-actions · 2026-03-09T21:21:51Z

Replacing with full review - see next comment

github-actions · 2026-03-09T21:22:17Z

Claude Code Review

Summary

This PR introduces a .mergify.yml to automate the merge queue using the Mergify GitHub App. The configuration is minimal and well-structured, but there are two meaningful gaps: the merge_method contradicts the project's documented commit convention, and several required CI checks (unit tests, lint) are absent from the queue gate.

Issues by Severity

Blocker Issues: None

Critical Issues: None

Major Issues

merge_method: rebase contradicts the project squash-merge convention

File: .mergify.yml line 4
Problem: CLAUDE.md explicitly states Conventional commits: Squashed on merge to main. Using rebase instead of squash means every individual commit from a feature branch is rebased directly onto main. This can land non-conventional commits (e.g., fixup or WIP commits) directly in the main history, breaking the project's conventional-commit log.
Standard violated: CLAUDE.md - Conventional commits: Squashed on merge to main
Suggested fix: Change merge_method to squash. Optionally add a commit_message_template to ensure the squashed commit follows conventional commit format.

Unit tests and lint are not required queue conditions

File: .mergify.yml lines 5-10
Problem: queue_conditions only gates on E2E tests, amber-review, detect-changes, validate-manifests, and test-local-dev-simulation. Unit tests (unit-tests.yml) and lint (lint.yml) are entirely absent. A PR with failing unit tests or lint violations would still be auto-merged once approved.
Standard violated: Quality gate principle - CI checks exist to protect main; omitting them from the merge gate defeats their purpose.
Suggested fix: Add the summary jobs from each workflow. Verify exact check names with gh pr checks on any open PR.

Minor Issues

check-success=detect-changes may be ambiguous

File: .mergify.yml line 8
Problem: Multiple workflows define a job named detect-changes (lint, unit-tests, e2e). In GitHub Actions, Mergify matches check-run names as workflow_name / job_name. The bare name detect-changes without a workflow qualifier may match unexpectedly or not at all. Since detect-changes is a path-filter helper rather than a real quality gate, requiring it adds minimal value.
Suggested fix: Remove this condition, or qualify it explicitly, e.g. check-success=Lint / detect-changes.

No dismissed-reviews guard

File: .mergify.yml lines 13-16
Problem: The enqueue condition approved-reviews-by>=1 does not guard against PRs where a prior approval was dismissed after a significant change. Mergify does not handle dismissed reviews automatically.
Suggested fix: Add changes-requested-reviews-by=0 to prevent enqueueing PRs with outstanding change requests.

Positive Highlights

Correct gate philosophy: Requiring amber-review, End-to-End Tests, validate-manifests, and test-local-dev-simulation is well-aligned with the project quality bar and ensures agentic sessions and manifests are validated before landing.
YAML syntax verified by the author before submitting - good hygiene.
Linear history intent is sound; the only issue is choosing rebase over squash for a project that documents squash-on-merge and conventional commits.

Recommendations

(Most important) Change merge_method: rebase to squash to align with CLAUDE.md's Squashed on merge to main convention.
Add unit-test and lint summary checks to queue_conditions so failing tests or lint violations block auto-merge.
Add changes-requested-reviews-by=0 to enqueue conditions to guard against dismissed reviews.
Remove or qualify check-success=detect-changes - it is a path-filter helper, not a quality gate.

github-actions · 2026-03-09T21:29:23Z

test

github-actions · 2026-03-09T21:30:20Z

Placeholder - will edit

github-actions · 2026-03-09T21:30:36Z

Claude Code Review - Summary: This PR introduces a .mergify.yml. Two gaps found: merge_method contradicts squash convention, and unit tests and lint are absent from queue gate. Major Issue 1: merge_method rebase contradicts squash-merge convention (CLAUDE.md). Major Issue 2: Unit tests and lint not required in queue_conditions. Minor: detect-changes ambiguous, no dismissed-reviews guard. Recommendations: Change to squash, add unit-test and lint checks, add changes-requested guard, remove or qualify detect-changes.

github-actions · 2026-03-09T21:31:14Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T21:32:29Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T21:34:12Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T21:37:07Z

Claude Code Review

Summary

This PR introduces a .mergify.yml to automate the merge queue using the Mergify GitHub App. The configuration is minimal and well-structured, but there are two meaningful gaps: the merge_method contradicts the project's documented commit convention, and several required CI checks (unit tests, lint) are absent from the queue gate.

Issues by Severity

Blocker Issues

None

Critical Issues

None

Major Issues

1. merge_method: rebase contradicts the project squash-merge convention

File: .mergify.yml:4
Problem: CLAUDE.md explicitly states "Conventional commits: Squashed on merge to main". Using rebase instead of squash means every individual commit from a feature branch is rebased directly onto main. This can land non-conventional commits (e.g., fixup or WIP commits) directly in the main history, breaking the project's conventional-commit log.
Standard violated: CLAUDE.md — "Conventional commits: Squashed on merge to main"
Suggested fix: Change merge_method to squash. Optionally add a commit_message_template to enforce conventional commit format.

2. Unit tests and lint are not required queue conditions

File: .mergify.yml:5-10
Problem: queue_conditions only gates on E2E tests, amber-review, detect-changes, validate-manifests, and test-local-dev-simulation. Unit tests (unit-tests.yml) and lint (lint.yml) are entirely absent. A PR with failing unit tests or lint violations would still be auto-merged once approved.
Standard violated: Quality gate principle — CI checks exist to protect main; omitting them from the merge gate defeats their purpose.
Suggested fix: Add the summary jobs from each workflow (they aggregate sub-job results). Verify exact check names with gh pr checks on any open PR.

Minor Issues

1. check-success=detect-changes may be ambiguous

File: .mergify.yml:8
Problem: Multiple workflows define a job named detect-changes (lint, unit-tests, e2e). In GitHub Actions, Mergify matches check-run names as {workflow_name} / {job_name}. The bare name detect-changes without a workflow qualifier may match unexpectedly or not at all. Since detect-changes is a path-filter helper, not a quality gate, requiring it adds minimal value over the downstream jobs that already depend on it.
Suggested fix: Remove this condition, or qualify it: check-success=Lint / detect-changes.

2. No dismissed-reviews guard

File: .mergify.yml:13-16
Problem: The enqueue condition approved-reviews-by>=1 does not guard against PRs where a prior approval was dismissed after a significant change. Mergify does not handle dismissed reviews automatically.
Suggested fix: Add changes-requested-reviews-by=0 to prevent enqueueing PRs with outstanding change requests.

Positive Highlights

Correct gate philosophy: Requiring amber-review, End-to-End Tests, validate-manifests, and test-local-dev-simulation is well-aligned with the project quality bar and ensures agentic sessions and manifests are validated before landing.
YAML syntax verified by the author before submitting — good hygiene.
Linear history intent is sound; the only issue is choosing rebase over squash for a project that documents squash-on-merge and conventional commits.

Recommendations

(Most important) Change merge_method: rebase to squash to align with CLAUDE.md's documented "Squashed on merge to main" convention.
Add unit-test and lint summary checks to queue_conditions so failing tests or lint violations block auto-merge.
Add a changes-requested-reviews-by=0 condition to enqueue conditions to guard against dismissed reviews.
Remove or qualify check-success=detect-changes — it is a path-filter helper, not a quality gate.

github-actions · 2026-03-09T22:30:56Z

Claude Code Review

Summary

This PR adds a .mergify.yml configuration file to enable automated merge queue management via the Mergify GitHub App. The change is infrastructure-only, small in scope, and aligns well with the project squash-merge convention. One minor inconsistency between the PR description and the actual configuration was found.

Issues by Severity

Blocker Issues

None

Critical Issues

None

Major Issues

None

Minor Issues

1. PR description contradicts actual merge method

File: .mergify.yml line 3 and PR body
Problem: The PR description states "Uses rebase merge method to keep a linear commit history", but the configuration sets merge_method: squash. Squash and rebase are different strategies - squash collapses all commits into one; rebase replays them linearly onto the target branch.
Standard violated: CLAUDE.md states "Conventional commits: Squashed on merge to main", confirming squash is the intended method. The code is correct; only the description needs updating.

2. queue action has no explicit name property

File: .mergify.yml line 15
Problem: The queue action block has no name sub-property, implicitly targeting the queue named default. This works today because the only defined queue_rule is named default, but would be fragile if additional named queues are added later.
Suggested fix: Add name: default under the queue action.

Positive Highlights

Correct merge method: merge_method: squash is exactly right per CLAUDE.md ("Squashed on merge to main"). The PR description is misleading but the configuration itself is correct.
Strong CI gate: queue_conditions requires four CI checks (End-to-End Tests, amber-review, validate-manifests, test-local-dev-simulation) to pass before any merge - a meaningful quality gate.
Changes-requested block: The condition "#changes-requested-reviews-by=0" correctly prevents PRs from entering the queue while review feedback is outstanding, avoiding premature merges.
Minimal footprint: The config is concise and introduces no unnecessary complexity.

Recommendations

(Minor) Correct the PR description to say squash instead of rebase to avoid confusion in git history and changelog.
(Minor, optional) Add an explicit name: default under the queue action for resilience against future multi-queue configurations.

Reviewed by Claude Code - Model: claude-sonnet-4-6

Mergify enqueues approved PRs, rebases them onto the target branch, and merges once CI passes. This replaces manual merge coordination and ensures every PR lands with a clean rebase. The repo also needs the "Require review from Code Owners" branch protection setting enabled in GitHub for CODEOWNERS enforcement to take effect. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

github-actions · 2026-03-09T22:39:19Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T22:39:41Z

Bookmarks

Progressive disclosure for task-specific documentation and references.

Architecture Decisions

ADR-0001: Kubernetes-Native Architecture

Why the platform uses CRDs, operators, and Job-based execution instead of a traditional API.

ADR-0002: User Token Authentication

Why user tokens are used for API operations instead of service accounts.

ADR-0003: Multi-Repo Support

Design for operating on multiple repositories in a single session.

ADR-0004: Go Backend, Python Runner

Language choices for each component and why.

ADR-0005: NextJS + Shadcn + React Query

Frontend technology stack decisions.

ADR-0006: Ambient Runner SDK Architecture

Runner SDK design and architecture.

Development Context

Backend Development Context

Go backend patterns, K8s integration, handler conventions, user-scoped client usage.

Frontend Development Context

NextJS patterns, Shadcn UI usage, React Query data fetching, component guidelines.

Security Standards

Auth flows, RBAC enforcement, token handling, container security patterns.

Code Patterns

Error Handling Patterns

Consistent error patterns across backend, operator, and runner.

K8s Client Usage Patterns

When to use user token vs. service account clients. Critical for RBAC compliance.

React Query Usage Patterns

Data fetching hooks, mutations, cache invalidation, optimistic updates.

Component Guides

Backend README

Go API development, testing, handler structure.

Backend Test Guide

Testing strategies, test utilities, integration test setup.

Frontend README

NextJS development, local setup, environment config.

Frontend Design Guidelines

Component patterns, Shadcn usage, type conventions, pre-commit checklist.

Frontend Component Patterns

Architecture patterns for React components.

Operator README

Operator development, watch patterns, reconciliation loop.

Runner README

Python runner development, Claude Code SDK integration.

Public API README

Stateless gateway design, token forwarding, input validation.

Development Environment

Kind Local Development

Recommended local dev setup using Kind (Kubernetes in Docker).

CRC Local Development

OpenShift Local (CRC) setup for OpenShift-specific features.

Minikube Setup

Older approach, still supported.

Hybrid Development

Run components locally with breakpoint debugging.

Manifests README

Kustomize overlay structure, deploy.sh usage.

Testing

E2E Testing Guide

Writing and running Cypress E2E tests.

E2E README

Running E2E tests, environment setup, CI integration.

Observability

Observability Overview

Monitoring, metrics, and tracing architecture.

Langfuse Integration

LLM tracing with privacy-preserving defaults.

Operator Metrics

Grafana dashboards for operator metrics.

Design Documents

Declarative Session Reconciliation

Session lifecycle management through declarative status transitions.

Runner-Operator Contract

Interface contract between operator and runner pods.

Session Status Redesign

Status field evolution and phase transitions.

Session Initialization Flow

How sessions are initialized and configured.

Spec-Runtime Synchronization

Keeping spec and runtime state in sync.

Amber Automation

Amber Config

Automation policies and label mappings.

github-actions · 2026-03-09T22:40:42Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T22:41:12Z

Test comment - checking connectivity

github-actions · 2026-03-09T22:42:19Z

Ambient Code Platform

Kubernetes-native AI automation platform that orchestrates agentic sessions through containerized microservices. Built with Go (backend, operator), NextJS + Shadcn (frontend), Python (runner), and Kubernetes CRDs.

Technical artifacts still use "vteam" for backward compatibility.

Structure

components/backend/ - Go REST API (Gin), manages K8s Custom Resources with multi-tenant project isolation
components/frontend/ - NextJS web UI for session management and monitoring
components/operator/ - Go Kubernetes controller, watches CRDs and creates Jobs
components/runners/ambient-runner/ - Python runner executing Claude Code CLI in Job pods
components/ambient-cli/ - Go CLI (acpctl), manages agentic sessions from the command line
components/public-api/ - Stateless HTTP gateway, proxies to backend (no direct K8s access)
components/manifests/ - Kustomize-based deployment manifests and overlays
e2e/ - Cypress end-to-end tests
docs/ - Astro Starlight documentation site

Key Files

CRD definitions: components/manifests/base/crds/agenticsessions-crd.yaml, projectsettings-crd.yaml
Session lifecycle: components/backend/handlers/sessions.go, components/operator/internal/handlers/sessions.go
Auth & RBAC middleware: components/backend/handlers/middleware.go
K8s client init: components/operator/internal/config/config.go
Runner entry point: components/runners/ambient-runner/main.py
Route registration: components/backend/routes.go
Frontend API layer: components/frontend/src/services/api/, src/services/queries/

Session Flow

User Creates Session → Backend Creates CR → Operator Spawns Job →
Pod Runs Claude CLI → Results Stored in CR → UI Displays Progress

Commands

make build-all                # Build all container images
make deploy                   # Deploy to cluster
make test                     # Run tests
make lint                     # Lint code
make kind-up                  # Start local Kind cluster
make test-e2e-local           # Run E2E tests against Kind

Per-Component

# Backend / Operator (Go)
cd components/backend && gofmt -l . && go vet ./... && golangci-lint run
cd components/operator && gofmt -l . && go vet ./... && golangci-lint run

# Frontend
cd components/frontend && npm run build  # Must pass with 0 errors, 0 warnings

# Runner (Python)
cd components/runners/ambient-runner && uv venv && uv pip install -e .

# Docs
cd docs && npm run dev  # http://localhost:4321

Critical Context

User token auth required: All user-facing API ops use GetK8sClientsForRequest(c), never the backend service account
OwnerReferences on all child resources: Jobs, Secrets, PVCs must have controller owner refs
No panic() in production: Return explicit fmt.Errorf with context
No any types in frontend: Use proper types, unknown, or generic constraints
Conventional commits: Squashed on merge to main

Pre-commit Hooks

The project uses the pre-commit framework to run linters locally before every commit. Configuration lives in .pre-commit-config.yaml.

Install

make setup-hooks

What Runs

On every git commit:

Hook	Scope
trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files, check-merge-conflict, detect-private-key	All files
ruff-format, ruff (check + fix)	Python (runners, scripts)
gofmt, go vet, golangci-lint	Go (backend, operator, public-api — per-module)
eslint	Frontend TypeScript/JavaScript
branch-protection	Blocks commits to main/master/production

On every git push:

Hook	Scope
push-protection	Blocks pushes to main/master/production

Run Manually

make lint                                    # All hooks, all files
pre-commit run gofmt-check --all-files       # Single hook
pre-commit run --files path/to/file.go       # Single file

Skip Hooks

git commit --no-verify    # Skip pre-commit hooks
git push --no-verify      # Skip pre-push hooks

Notes

Go and ESLint wrappers (scripts/pre-commit/) skip gracefully if the toolchain is not installed
tsc --noEmit and npm run build are not included (slow; CI gates on them)
Branch/push protection scripts remain in scripts/git-hooks/ and are invoked by pre-commit

Testing

Frontend unit tests: cd components/frontend && npx vitest run --coverage (466 tests, ~74% coverage). See components/frontend/README.md.
E2E tests: cd e2e && npx cypress run --browser chrome (58 tests, mock SDK). See e2e/README.md.
Runner tests: cd components/runners/ambient-runner && python -m pytest tests/
Backend tests: cd components/backend && make test. See components/backend/TEST_GUIDE.md.

More Info

See BOOKMARKS.md for architecture decisions, development context, code patterns, and component-specific guides.

github-actions · 2026-03-09T22:43:26Z

Linux version 6.14.0-1017-azure (buildd@lcy02-amd64-074) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #17~~24.04.1-Ubuntu SMP Mon Dec 1 20:10:50 UTC 2025

github-actions · 2026-03-09T22:43:40Z

test

github-actions · 2026-03-09T22:44:21Z

Test comment 2 - checking write permissions before review

github-actions · 2026-03-09T22:45:35Z

Claude Code Review

Summary

This PR introduces a .mergify.yml configuration establishing an automated merge queue. The implementation is minimal and well-focused: it squash-merges PRs after CI passes and a human approval is recorded. The config aligns with the project documented conventions (squash merges to main). Overall this is a low-risk, clean infrastructure change with no security or architectural concerns.

Issues by Severity

Blocker Issues: None

Critical Issues: None

Major Issues: None

Minor Issues

1. No base=main filter on the enqueue rule - .mergify.yml lines 11-17

The pull_request_rules condition does not restrict which base branch the rule applies to. Any PR targeting any branch that receives one approval will be enqueued. Defensive scoping is recommended. Suggested fix: add base=main and draft=false to the conditions list alongside the existing approval checks.

2. Squash commit message template not specified - .mergify.yml line 4

With merge_method: squash and no commit_message_template, Mergify defaults to combining all commit messages from the PR, producing noisy squash commits on main. The project uses conventional commits (per CLAUDE.md). Suggested fix: add commit_message_template: "{{ title }} (#{{ number }})" under the queue rule.

3. PR description references CODEOWNERS but no CODEOWNERS file exists

The PR description states the queue satisfies CODEOWNERS requirements, but no CODEOWNERS file exists in the repository. approved-reviews-by>=1 allows any single approver to trigger the queue, which is fine for the current state but slightly misleading. Consider adding a CODEOWNERS file if team-specific review requirements are intended.

Positive Highlights

Squash merge correctly aligns with project standards. merge_method: squash matches the CLAUDE.md convention ("Conventional commits: Squashed on merge to main") with no gap.
Queue conditions represent a solid quality gate. Requiring End-to-End Tests, amber-review, validate-manifests, and test-local-dev-simulation before merging ensures PRs are thoroughly validated before landing on main.
Self-referential amber-review gate. Including check-success=amber-review in queue_conditions means AI code review must pass before any merge - a good feedback loop.
File is appropriately minimal. 17 lines with no unnecessary complexity - exactly what is needed and nothing more.

Recommendations

(Minor, recommended before merge) Add base=main and draft=false conditions to pull_request_rules to prevent accidental enqueuing of non-main or in-progress PRs.
(Nice-to-have) Add a commit_message_template to control squash commit message format and keep main history consistent with conventional commits style.
(Post-merge) Consider adding a CODEOWNERS file if the team wants to enforce that PRs touching specific components require review from specific individuals.

Review generated by Amber / Claude Code

github-actions · 2026-03-09T22:51:21Z

Claude Code Review

Summary

This PR adds a .mergify.yml to automate the merge queue via the Mergify GitHub App. The change is minimal (17 lines), tightly scoped, and introduces squash-merge with approval-gated queue entry. The configuration aligns well with the project’s documented conventions.

Issues by Severity

Blocker Issues

None

Critical Issues

None

Major Issues

None

Minor Issues

1. PR description says “rebase” but config uses squash

The description states the queue “rebases and merges” PRs, but merge_method: squash is configured — not rebase. This is a documentation inconsistency only, not a code defect, but may cause confusion about the actual merge strategy.

Suggested fix: Update the PR description to say “squash-merges” to accurately reflect the behavior.

2. No update_method to keep PRs current before merge

File: .mergify.yml

The queue will process PRs without explicitly ensuring they are rebased onto the latest base branch before the squash-merge. In high-velocity scenarios a PR with passing CI could land on a stale base. Adding update_method: rebase would close this window if branch protection does not already enforce it.

3. CI gate completeness cannot be fully verified from the diff

File: .mergify.yml:5-8

The four required checks (End-to-End Tests, amber-review, validate-manifests, test-local-dev-simulation) look reasonable based on recent commit history, but without seeing all workflow definitions it is not possible to confirm that backend unit tests, frontend build, and operator tests are gated here or subsumed under one of these check names.

Suggested action: Cross-check these four names against all GitHub Actions workflow job names to ensure no critical gate is missing.

Positive Highlights

merge_method: squash is exactly right. CLAUDE.md specifies conventional commits squashed on merge to main; this config enforces that at the automation layer with no room for human error.
The #changes-requested-reviews-by=0 condition is a strong safety gate. PRs with outstanding change requests cannot enter the queue, preventing the approve-after-requesting-changes bypass pattern.
Including amber-review as a required check creates a self-reinforcing quality loop — automated code review must pass before automated merge proceeds.
Minimal and non-invasive. The config avoids speculative merges, batch queuing, and complex priority schemes, which is appropriate for the team’s current scale.
YAML syntax was validated as part of the stated test plan, which is good hygiene before merging automation configuration.

Recommendations

(Low priority) Fix the PR description to say “squash-merges” rather than “rebase and merges”.
(Low priority) Audit the four check names against all GHA workflow job names to confirm full coverage of critical CI gates.
(Optional) Consider update_method: rebase if branch protection does not already require branches to be up to date before merging.

Review performed by Claude Code using repository standards from .claude/context/ and .claude/patterns/.

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

CLAUDE.md - Master project instructions, development standards
backend-development.md - Go backend, K8s integration patterns
frontend-development.md - NextJS, Shadcn UI, React Query patterns
security-standards.md - Auth, RBAC, token handling
k8s-client-usage.md - User token vs service account patterns
error-handling.md - Consistent error patterns
react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.

ktdreyer · 2026-03-10T14:57:53Z

Idea from @mprpic : Instead of hard-coding the GH Action job names in .mergify.yml, find some way to say "all CI jobs must pass".

Mergify itself does not have support for this. One option I researched: build a new ci-gatekeeper job that watches all other jobs and reports on their status. However, that just moves the list of jobs to a needs: block in that ci-gatekeeper workflow.

mprpic

LGTM!

ktdreyer force-pushed the add-mergify-config branch from 9050586 to fe24f8c Compare March 9, 2026 22:36

ktdreyer enabled auto-merge (squash) March 9, 2026 22:50

ktdreyer requested a review from mprpic March 10, 2026 14:44

mprpic approved these changes Mar 10, 2026

View reviewed changes

ktdreyer merged commit 07d50e5 into main Mar 10, 2026
7 checks passed

ktdreyer deleted the add-mergify-config branch March 10, 2026 15:11

Conversation

ktdreyer commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Prerequisites

Test plan

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Uh oh!

github-actions bot commented Mar 9, 2026

Ambient Code Platform

Structure

Key Files

Session Flow

Commands

Per-Component

Critical Context

Pre-commit Hooks

Install

What Runs

Run Manually

Skip Hooks

Notes

Testing

More Info

Uh oh!

github-actions bot commented Mar 9, 2026

Ambient Code Platform

Structure

Key Files

Session Flow

Commands

Per-Component

Critical Context

Pre-commit Hooks

Install

What Runs

Run Manually

Skip Hooks

Notes

Testing

More Info

Uh oh!

github-actions bot commented Mar 9, 2026

Ambient Code Platform

Structure

Key Files

Session Flow

Commands

Per-Component

Critical Context

Pre-commit Hooks

Install

What Runs

Run Manually

Skip Hooks

Notes

Testing

More Info

Uh oh!

github-actions bot commented Mar 9, 2026

Claude Code Review

ktdreyer commented Mar 9, 2026 •

edited

Loading

github-actions bot commented Mar 9, 2026 •

edited

Loading

github-actions bot commented Mar 9, 2026 •

edited

Loading

github-actions bot commented Mar 9, 2026 •

edited

Loading