fips-agents-cli 0.5.1__tar.gz → 0.6.0__tar.gz

{fips_agents_cli-0.5.1 → fips_agents_cli-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: fips-agents-cli
-Version: 0.5.1
+Version: 0.6.0
 Summary: CLI tool for creating and managing FIPS-compliant AI agent projects
 Project-URL: Homepage, https://github.com/rdwj/fips-agents-cli
 Project-URL: Repository, https://github.com/rdwj/fips-agents-cli
@@ -38,7 +38,7 @@ A command-line tool for creating and managing FIPS-compliant AI agent projects.
 ## Features
 
 - 🚀 Quick project scaffolding from templates
-- 📦 MCP server, AI agent, Go gateway, chat UI, and ModelCar project generation
+- 📦 MCP server, AI agent, Go gateway, chat UI, sandbox, and ModelCar project generation
 - 🔧 Automatic project customization (pyproject.toml, module names, entry points)
 - ⚡ Component generation (tools, resources, prompts, middleware) with Jinja2 templates
 - 🎨 Beautiful CLI output with Rich
@@ -106,6 +106,9 @@ fips-agents create gateway my-gateway
 # Chat UI (connects to a gateway or agent)
 fips-agents create ui my-chat-ui
 
+# Code execution sandbox (sidecar for agents)
+fips-agents create sandbox my-sandbox
+
 # ModelCar (HuggingFace model as container)
 fips-agents create model-car ibm-granite/granite-3.1-2b-instruct \
     quay.io/user/models:granite-3.1-2b-instruct
@@ -273,6 +276,33 @@ fips-agents create ui my-chat-ui
 fips-agents create ui my-chat-ui --github --private
 ```
 
+#### `create sandbox`
+
+```bash
+fips-agents create sandbox <project-name> [OPTIONS]
+```
+
+Creates a code execution sandbox project from the [code-sandbox](https://github.com/fips-agents/code-sandbox) repository. The sandbox provides a FastAPI-based sidecar for secure code execution inside agent pods, with multiple language profiles (base, data-science).
+
+**Arguments:**
+
+- `project-name` -- Name for your sandbox project
+
+**Options:** Same shared options as above.
+
+**Examples:**
+
+```bash
+# Create sandbox project
+fips-agents create sandbox my-sandbox
+
+# Create with GitHub repo
+fips-agents create sandbox my-sandbox --github --private
+
+# Non-interactive mode
+fips-agents create sandbox my-sandbox --yes --local
+```
+
 #### `create model-car`
 
 ```bash
@@ -625,6 +655,16 @@ make build-openshift PROJECT=my-chat-ui  # Build on OpenShift
 make deploy PROJECT=my-chat-ui           # Deploy via Helm
 ```
 
+### Sandbox
+
+```bash
+cd my-sandbox
+make install             # Install dependencies
+make test                # Run tests
+make build               # Build container
+make build PROFILE=data-science  # Build with profile
+```
+
 ### ModelCar
 
 ```bash

{fips_agents_cli-0.5.1 → fips_agents_cli-0.6.0}/README.md

@@ -5,7 +5,7 @@ A command-line tool for creating and managing FIPS-compliant AI agent projects.
 ## Features
 
 - 🚀 Quick project scaffolding from templates
-- 📦 MCP server, AI agent, Go gateway, chat UI, and ModelCar project generation
+- 📦 MCP server, AI agent, Go gateway, chat UI, sandbox, and ModelCar project generation
 - 🔧 Automatic project customization (pyproject.toml, module names, entry points)
 - ⚡ Component generation (tools, resources, prompts, middleware) with Jinja2 templates
 - 🎨 Beautiful CLI output with Rich
@@ -73,6 +73,9 @@ fips-agents create gateway my-gateway
 # Chat UI (connects to a gateway or agent)
 fips-agents create ui my-chat-ui
 
+# Code execution sandbox (sidecar for agents)
+fips-agents create sandbox my-sandbox
+
 # ModelCar (HuggingFace model as container)
 fips-agents create model-car ibm-granite/granite-3.1-2b-instruct \
     quay.io/user/models:granite-3.1-2b-instruct
@@ -240,6 +243,33 @@ fips-agents create ui my-chat-ui
 fips-agents create ui my-chat-ui --github --private
 ```
 
+#### `create sandbox`
+
+```bash
+fips-agents create sandbox <project-name> [OPTIONS]
+```
+
+Creates a code execution sandbox project from the [code-sandbox](https://github.com/fips-agents/code-sandbox) repository. The sandbox provides a FastAPI-based sidecar for secure code execution inside agent pods, with multiple language profiles (base, data-science).
+
+**Arguments:**
+
+- `project-name` -- Name for your sandbox project
+
+**Options:** Same shared options as above.
+
+**Examples:**
+
+```bash
+# Create sandbox project
+fips-agents create sandbox my-sandbox
+
+# Create with GitHub repo
+fips-agents create sandbox my-sandbox --github --private
+
+# Non-interactive mode
+fips-agents create sandbox my-sandbox --yes --local
+```
+
 #### `create model-car`
 
 ```bash
@@ -592,6 +622,16 @@ make build-openshift PROJECT=my-chat-ui  # Build on OpenShift
 make deploy PROJECT=my-chat-ui           # Deploy via Helm
 ```
 
+### Sandbox
+
+```bash
+cd my-sandbox
+make install             # Install dependencies
+make test                # Run tests
+make build               # Build container
+make build PROFILE=data-science  # Build with profile
+```
+
 ### ModelCar
 
 ```bash

fips_agents_cli-0.6.0/planning/agent-registry-roadmap.md

@@ -0,0 +1,156 @@
+# Agent Registry — Research and Roadmap
+
+**Date:** 2026-04-10
+**Status:** Research complete, not yet planned for implementation
+
+## Concept
+
+`fips-agents create registry my-registry` deploys a self-hosted registry to OpenShift with a UI for browsing and managing registered agents, MCP servers, tools, and prompts. Teams register their deployed services with `fips-agents register`, making them discoverable across the organization.
+
+## Industry Landscape (April 2026)
+
+### What exists
+
+**Agent discovery standards:**
+- **A2A Agent Cards** — JSON metadata at `/.well-known/agent.json` describing an agent's capabilities, endpoints, and auth. Linux Foundation stewardship. No registry standard yet (active discussion in a2aproject/A2A#741).
+- **MCP Server Cards** — `.well-known` metadata for MCP servers, on the 2026 MCP roadmap. The official MCP Registry (registry.modelcontextprotocol.io) has ~2,000 entries but is public/community-oriented, not enterprise.
+- **Agent Connect Protocol (ACP)** — Cisco-led (AGNTCY/Linux Foundation), defines REST/OpenAPI for invoking and configuring agents. Complements A2A.
+
+**Cloud provider registries:**
+- **AWS Agent Registry** (preview April 2026) — private governed catalog for agents, tools, skills, MCP servers. Semantic search, approval workflows, IAM + OAuth, CloudTrail audit. Auto-discovers from live A2A/MCP endpoints.
+- **Microsoft Entra Agent Registry** — agent identity and governance in the Microsoft ecosystem.
+- **Google Vertex AI Agent Builder** — tool governance layer with admin-curated catalogs.
+
+**Open source:**
+- **mcp-gateway-registry** (agentic-community) — OAuth (Keycloak/Entra), per-tool RBAC, audit trails, reverse proxy to MCP servers. Closest to what we'd want.
+- **kagent** — Kubernetes-native agentic AI, CRD-based. Early stage.
+
+**Prompt registries:**
+- MLflow Prompt Registry, Langfuse, PromptLayer, LangSmith — versioning, environment aliases, A/B testing. Standalone products, not integrated with agent/tool registries.
+
+**Red Hat direction:**
+- MCP registry, catalog, and gateway stack planned for OpenShift AI
+- MCP servers as items in the AI Assets catalog
+- Longer-term "MCP-as-a-Service" vision
+
+### What's missing
+
+No single open-source system unifies agents, MCP servers, tools, and prompts in one governed catalog with Kubernetes-native lifecycle. The pieces exist in isolation:
+- AWS has the richest registry but is cloud-locked
+- MCP has a public registry but no enterprise governance
+- Prompt registries are standalone products
+- RBAC is protocol-specific (no cross-protocol standard)
+- A2A deliberately punts on the registry problem
+
+### RBAC for agents
+
+Traditional RBAC is insufficient — agents chain multi-step plans autonomously. Emerging model is **dynamic RBAC**: bind an agent's declared purpose + operational context + verified identity to minimal, temporary permissions. Per-tool RBAC (mcp-gateway-registry), relationship-based access (Oso ReBAC), and IAM-based governance (AWS) are the main approaches.
+
+## What We'd Build
+
+### Phase 1: Discovery registry (near-term, after composable capabilities)
+
+A lightweight catalog service that stores and serves metadata:
+
+```
+fips-agents create registry my-registry    # Deploy to OpenShift
+fips-agents register                       # Register current project
+```
+
+**What it stores:**
+- Agent Cards (A2A-compatible JSON) — name, description, capabilities, endpoint, version
+- MCP Server Cards — name, tools list, endpoint, transport
+- Tool manifests — name, description, parameters, which agent/MCP server provides them
+- Prompt entries — name, description, version, variables, template preview
+
+**How registration works:**
+- `fips-agents register` reads the current project type and metadata:
+  - Agent: reads `/.well-known/agent.json` from the running service (or generates from agent.yaml)
+  - MCP server: reads tool list from the running server (or from project structure)
+  - Prompts: reads from `prompts/` directory
+- Pushes the metadata to the registry's API
+- Registry stores it and makes it browsable
+
+**UI:**
+- Browse agents, MCP servers, tools, prompts in a web dashboard
+- Search by name, capability, description
+- View agent cards, tool schemas, prompt templates
+- Show deployment status (healthy/unhealthy via health probes)
+- Links to OpenShift console for the underlying deployments
+
+**Tech stack:**
+- Go server (consistent with gateway/UI templates) or Python FastAPI
+- PostgreSQL for metadata storage
+- OpenShift Route for the UI
+- Helm chart for deployment
+- Periodic health checks against registered endpoints
+
+### Phase 2: Governance (later)
+
+Add approval workflows, RBAC, and audit:
+- Admin approval required before an agent/tool is visible to others
+- Role-based access: who can register, who can discover, who can invoke
+- Audit trail: who registered what, when, who accessed it
+- Integration with OpenShift RBAC (ServiceAccounts, Roles)
+- Keycloak/OIDC for auth (follow mcp-gateway-registry pattern)
+
+### Phase 3: Enterprise tool/prompt catalog (distant)
+
+- Curated enterprise tools that any agent can use (governed, versioned)
+- Enterprise prompt library with approval workflows
+- Agent RBAC: which agents can use which tools (policy-based)
+- Integration with Red Hat's AI Hub / OpenShift AI catalog
+
+## CLI Integration
+
+```bash
+# Deploy a registry
+fips-agents create registry my-registry
+cd my-registry && make deploy PROJECT=my-registry
+
+# Register the thing you're working on
+cd ../my-agent
+fips-agents register                          # auto-detect project type, register with default registry
+fips-agents register --registry my-registry   # explicit registry
+fips-agents register --type agent             # force type
+fips-agents register --type mcp-server
+
+# Browse
+fips-agents registry list                     # list all registered items
+fips-agents registry list --type agent        # filter by type
+fips-agents registry search "web search"      # semantic search
+```
+
+The `register` command could also be a post-deploy hook in the Makefile:
+```makefile
+deploy: ## Deploy to OpenShift and register
+	helm upgrade --install ...
+	fips-agents register --registry $(REGISTRY_URL)
+```
+
+## Open Questions
+
+1. **Storage**: PostgreSQL vs CRDs? CRDs are more Kubernetes-native but harder to query. PostgreSQL is simpler for search and UI.
+2. **Health monitoring**: Should the registry actively poll registered endpoints, or rely on passive registration updates?
+3. **Scope**: Should the registry be namespace-scoped, cluster-scoped, or multi-cluster?
+4. **Red Hat alignment**: How does this relate to Red Hat's planned MCP catalog in OpenShift AI? Complement or conflict?
+5. **Standards**: Should agent cards be A2A-native, or a superset that includes MCP/tool/prompt metadata?
+6. **Auth for registration**: How does `fips-agents register` authenticate with the registry? OpenShift token? API key?
+
+## Relationship to Other Roadmap Items
+
+- **HTTP mode** (Phase 1 of composable capabilities) must ship first — agents need `/.well-known/agent.json` to be registerable
+- **A2A agent cards** are already in the gateway template — the registry reads these
+- **MCP server template** already produces discoverable tools — the registry catalogs them
+- **Multi-agent orchestration** benefits most from a registry — orchestrator agents can discover specialized agents dynamically
+
+## References
+
+- A2A Protocol: https://a2a-protocol.org/latest/specification/
+- A2A Registry Discussion: https://github.com/a2aproject/A2A/discussions/741
+- MCP Registry: https://registry.modelcontextprotocol.io/
+- MCP 2026 Roadmap: https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/
+- mcp-gateway-registry: https://github.com/agentic-community/mcp-gateway-registry
+- AWS Agent Registry: https://aws.amazon.com/blogs/machine-learning/the-future-of-managing-agents-at-scale-aws-agent-registry-now-in-preview/
+- AGNTCY ACP Spec: https://github.com/agntcy/acp-spec
+- kagent: https://kagent.dev/

fips_agents_cli-0.6.0/planning/composable-agent-capabilities.md

@@ -0,0 +1,126 @@
+# Composable Agent Capabilities — Planning
+
+**Date:** 2026-04-10
+**Status:** Discussion, not yet implemented
+
+## Vision
+
+The CLI evolves from "scaffold once" to "scaffold + compose." Agents start lean and gain capabilities through `add` commands. Each capability is a template fragment (files, deps, config) that the CLI layers into an existing project.
+
+## Command Design
+
+### Current commands
+- `create agent|mcp-server|gateway|ui` — scaffold a new project
+- `generate tool|resource|prompt|middleware` — add a single MCP component from Jinja2 template
+
+### Proposed: `add` command
+- `add http` — FastAPI server + health probes + agent card + uvicorn CMD
+- `add tool <name>` — add a pre-built tool (web-search, code-executor, etc.)
+- `add memory` — MemoryHub integration (config init, dependency, schema)
+- `add rag` — RAG client (LlamaStack or equivalent connection, retrieval tool)
+- `add sessions` — conversation state persistence (Redis/PostgreSQL)
+- `add observability` — structured logging, metrics
+
+### Command relationship
+- `generate` creates a **single component file** from a Jinja2 template (MCP-oriented)
+- `add` layers a **whole capability** (multiple files, dependencies, config, tests)
+- `add tool` should detect project type (MCP server vs agent) and generate the right decorator/structure. This requires consistent tree structure across templates.
+
+### Slash command relationship
+- CLI `add` commands handle **structural changes** (files, deps, Containerfile)
+- Slash commands handle **behavioral configuration** (agent.yaml tuning, prompt design, tool parameters)
+- Example flow: `fips-agents add tool web-search` → `/configure-search` in Claude Code
+
+## Capability Tiers
+
+### Tier 1 — Almost every agent
+1. **HTTP mode** — FastAPI, /v1/chat/completions, health probes, A2A agent card
+2. **Web search** — Tavily/Brave with rate limiting
+3. **Observability** — structured logging, optional Prometheus metrics
+
+### Tier 2 — Common
+4. **Memory** — MemoryHub integration (already partially wired in base_agent)
+5. **Code execution** — sandboxed Python/shell via sidecar container
+6. **RAG** — client-side connection to LlamaStack or equivalent (not rebuilding RAG infra)
+7. **Sessions** — Redis/PostgreSQL conversation state
+
+### Tier 3 — Specialized
+8. **A2A discovery** — agent-to-agent calling, registry
+9. **Auth** — OAuth2/OIDC middleware
+10. **Multi-model routing** — cheap model for classification, expensive for generation
+11. **File handling** — upload/download, temp storage
+
+## Code Execution Design
+
+Recommended: **sidecar container** approach.
+- `add tool code-executor` adds the tool to the agent AND a sidecar to the Helm chart
+- Agent sends code to sidecar via localhost HTTP
+- Sidecar runs in a locked-down container (no network, resource limits, timeout)
+- Stronger isolation than in-process subprocess, simpler than managing a separate MCP server
+- Advanced path: MCP code-execution server for shared infrastructure
+
+## RAG Design
+
+Don't rebuild RAG — connect to it.
+- LlamaStack provides vector store, embedding, retrieval out of the box
+- `add rag` sets up the client side: config for the RAG endpoint, retrieval tool, ingestion tool
+- The RAG infrastructure (LlamaStack, vLLM for embeddings, vector DB) is separate
+- Agent template provides the wiring pattern, not the infrastructure
+- This will likely need a full session to design and implement properly
+
+## Multi-Agent Design
+
+Building blocks already exist:
+- Each agent has `/.well-known/agent.json` (A2A agent card)
+- Gateway routes between agents
+- UI connects to any OpenAI-compatible endpoint
+
+Orchestration pattern:
+- An "orchestrator" agent discovers other agents via their agent cards
+- Delegates subtasks via HTTP to specialized agents
+- Each agent is independently deployable and scalable
+- Gateway provides the routing layer
+
+This is the natural evolution of the current stack (agent + gateway + UI) into a multi-agent system. The `add a2a` command would wire up the discovery and calling patterns.
+
+## Memory Design
+
+MemoryHub integration is partially wired into base_agent already:
+- `agent.yaml` has a `memory:` section pointing to `.memoryhub.yaml`
+- `base_agent/memory.py` has `create_memory_client()` that falls back to NullMemoryClient
+- `add memory` command would: install memoryhub dep, run `memoryhub config init`, offer `/configure-memory` slash command for schema design
+
+This is a quick win — most of the framework code exists.
+
+## Prioritization
+
+### Phase 1: HTTP mode + `add` framework
+- HTTP mode is the #1 blocker (every agent that needs a URL)
+- Building the `add` infrastructure enables everything else
+- Reference implementation: `demo-fips-agent-builder/src/server.py`
+
+### Phase 2: Memory + web search as first `add` capabilities  
+- Memory (MemoryHub) is partially wired, quick to finish
+- Web search validates the `add tool` pattern (we have a working Tavily implementation)
+- These are two different shapes: memory is config/framework, web search is a tool file
+
+### Phase 3: Code executor + RAG client
+- Code executor validates the sidecar pattern (Helm chart changes)
+- RAG client connects to LlamaStack (full session needed for design)
+
+### Phase 4: Multi-agent orchestration
+- A2A discovery and inter-agent calling
+- Orchestrator pattern on top of the gateway
+- Builds on HTTP mode foundation
+
+## Open Questions
+
+1. Should `add tool` auto-detect project type (MCP vs agent) or require explicit context?
+2. Where do capability template fragments live — in the CLI package, or in the template repos?
+3. How do we version capability fragments independently from the base templates?
+4. For RAG: do we standardize on LlamaStack, or support multiple backends?
+5. For multi-agent: does the gateway need to become aware of multiple backends, or is that a separate orchestration layer?
+
+## Key Bug Found This Session
+
+redhat-ai-americas/agent-template#19: The example agent doesn't append the assistant's tool_use message before tool_result messages, violating the Anthropic API contract. Must fix before HTTP mode ships, since it affects every agent using Anthropic.

{fips_agents_cli-0.5.1 → fips_agents_cli-0.6.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "fips-agents-cli"
-version = "0.5.1"
+version = "0.6.0"
 description = "CLI tool for creating and managing FIPS-compliant AI agent projects"
 readme = "README.md"
 requires-python = ">=3.10"

fips_agents_cli-0.6.0/retrospectives/2026-04-10_full-stack-integration/RETRO.md

@@ -0,0 +1,64 @@
+# Retrospective: Full Stack Integration and Agent Template Fixes
+
+**Date:** 2026-04-10
+**Effort:** Integration test UI → Gateway → Agent on OpenShift, fix all agent template bugs, close gateway/UI issues, release v0.5.1, build a working search agent, plan composable capabilities
+**Issues closed:** gateway-template #1, #4, #5; ui-template #2, #5; agent-template 12 bugs (no issue tracker)
+**Filed:** agent-template #19 (tool_use message ordering)
+**Release:** v0.5.1 (PyPI)
+**Commits:** 9748e0b..03927b7 (CLI), 4993c05..cc36289 (gateway), add7901..84ef204 (UI), 9efa650..4093298 (agent-template)
+
+## What We Set Out To Do
+
+1. Integration test the full stack (UI → Gateway → Agent) on OpenShift
+2. Fix bugs found during testing
+3. Close high-priority issues on gateway (#5 tests, #1 logging, #4 BuildConfig) and UI (#5 tests, #2 markdown)
+4. Fix all 12 agent-template bugs from the gap analysis
+5. Add HTTP mode to the agent template (stretch goal)
+
+## What Changed
+
+| Change | Type | Rationale |
+|--------|------|-----------|
+| Added reverse proxy to UI server | Good pivot | CORS issue discovered during integration — browser can't cross-origin fetch to gateway. Proxy is the correct architecture (keeps internal URLs internal). |
+| HTTP mode deferred | Scope deferral | Enough shipped without it. Building `add` command framework first makes the feature composable rather than baked-in. |
+| Composable capabilities planning | Good pivot | Search agent experience crystallized the vision — agents need layered capabilities, not monolithic templates. |
+| Agent registry research | Good pivot | User-initiated strategic planning. AWS launched Agent Registry the same day — validated the concept. |
+| v0.5.0 → v0.5.1 re-cut | Missed | Pre-existing Black formatting drift in two test files. Local `black --check` caught it but only on changed files; CI checks all files. |
+
+## What Went Well
+
+- **Full stack worked on first deploy** — agent, gateway, UI all running and streaming through three layers with no proxy/SSE bugs
+- **Parallel agent execution** — gateway tests, UI tests, and markdown rendering all built concurrently. Agent-template Python fixes and infra fixes also ran in parallel. Significant time savings.
+- **OpenShift BuildConfig** replaced ec2-dev remote builds cleanly — simpler, no external dependency
+- **Search agent validated the scaffolding end-to-end** — `create agent` → customize → real Tavily + Anthropic → working agent in minutes
+- **Bug fix thoroughness** — all 12 template bugs fixed, verified by separate review agent, 360 tests passing
+- **Chat UI was surprisingly polished** — streaming, markdown rendering, responsive design all worked well in the browser
+
+## Gaps Identified
+
+| Gap | Severity | Resolution |
+|-----|----------|------------|
+| v0.5.0 CI failed (Black drift in test files we didn't touch) | Fixed | Committed formatting, re-cut as v0.5.1 |
+| Tool_use/tool_result message ordering bug in example agent | Follow-up issue | agent-template#19 |
+| No CI workflows on gateway-template or ui-template repos | Follow-up | Tests exist and pass locally but no GitHub Actions |
+| `generate tool` vs `add tool` command overlap unresolved | Follow-up | Design captured in planning/composable-agent-capabilities.md |
+| ResearchAssistant example is overcomplex for a starting point | Accept | Will simplify when HTTP mode ships |
+
+## Action Items
+
+- [ ] Fix agent-template#19 (tool_use ordering) — blocks Anthropic-powered agents
+- [ ] Add CI workflows to gateway-template and ui-template repos
+- [ ] Build HTTP mode and `add` command framework (next session priority)
+- [ ] Add MemoryHub and web-search as first `add` capabilities
+
+## Patterns
+
+**Start:** Run `black --check src tests` (all files, not just changed) before cutting a release. The CI checks everything; local checks should match.
+
+**Start:** When building agent step loops that use tool calling, always append the assistant message (with tool_calls) before appending tool results. This is an Anthropic API requirement and should be documented in the template.
+
+**Continue:** Parallel sub-agent execution for independent work streams — consistently saves time with no coordination overhead.
+
+**Continue:** OpenShift BuildConfig for builds — simpler than remote builds, no external infrastructure needed.
+
+**Continue:** Deploying and testing the real stack on OpenShift rather than just running unit tests locally. The CORS issue, WORKDIR permissions, and tool_use ordering bug were all found only through integration testing.