mirror of
https://github.com/katanemo/plano.git
synced 2026-06-17 15:25:17 +02:00
feat: update text
This commit is contained in:
parent
39096c6b90
commit
b28434a5f1
4 changed files with 372 additions and 17 deletions
|
|
@ -31,18 +31,17 @@ export function Hero() {
|
|||
|
||||
{/* Main Heading */}
|
||||
<h1 className="text-4xl sm:text-4xl md:text-5xl lg:text-7xl font-normal leading-tight tracking-tighter text-black mb-4 sm:mb-6 flex flex-col gap-0 sm:-space-y-2 lg:-space-y-3">
|
||||
<span className="font-sans">Models-native </span>
|
||||
<span className="font-sans">Delivery infrastructure </span>
|
||||
<span className="font-sans font-medium text-[var(--secondary)]">
|
||||
dataplane for agents
|
||||
for agentic apps
|
||||
</span>
|
||||
</h1>
|
||||
</div>
|
||||
|
||||
{/* Subheading with CTA Buttons */}
|
||||
<div className="max-w-7xl flex flex-col lg:flex-row lg:items-end lg:justify-between gap-6">
|
||||
<p className="text-base sm:text-lg md:text-xl lg:text-2xl font-sans font-[400] tracking-[-1.2px] sm:tracking-[-1.92px]! text-black max-w-4xl">
|
||||
Build agents faster, and scale them reliably by offloading the
|
||||
plumbing work in AI.
|
||||
<p className="text-base sm:text-lg md:text-xl lg:text-2xl font-sans font-[400] tracking-[-1.2px] sm:tracking-[-1.82px]! text-black max-w-4xl">
|
||||
Build agents faster, and deliver them reliably to prod by offloading plumbing work in AI
|
||||
</p>
|
||||
|
||||
{/* CTA Buttons */}
|
||||
|
|
|
|||
|
|
@ -20,11 +20,10 @@ export function IntroSection() {
|
|||
{/* Body Text */}
|
||||
<div className="font-mono tracking-[-0.96px]! text-white text-sm sm:text-base lg:text-lg max-w-[713px]">
|
||||
<p className="mb-0">
|
||||
Plano is a framework-friendly proxy server and dataplane for
|
||||
agents, deployed as a sidecar. Plano handles the critical
|
||||
plumbing work in AI like agent routing and orchestration,
|
||||
comprehensive traces for agentic interactions, guardrail hooks,
|
||||
unified APIs for LLMs.
|
||||
Plano is a models-native proxy server and dataplane for agents
|
||||
that handles the critical plumbing work in AI like agent routing and
|
||||
orchestration, comprehensive traces for agentic interactions, guardrail
|
||||
hooks, unified APIs for LLMs
|
||||
</p>
|
||||
<p className="mb-0 mt-4">
|
||||
Developers can focus more on modeling workflows.
|
||||
|
|
|
|||
|
|
@ -11,16 +11,16 @@ const customerLogos = [
|
|||
src: "/logos/tmobile.svg",
|
||||
},
|
||||
{
|
||||
name: "Chase",
|
||||
src: "/logos/chase.svg",
|
||||
name: "HP",
|
||||
src: "/logos/hp.svg",
|
||||
},
|
||||
{
|
||||
name: "SanDisk",
|
||||
src: "/logos/sandisk.svg",
|
||||
},
|
||||
{
|
||||
name: "HP",
|
||||
src: "/logos/hp.svg",
|
||||
name: "Chase",
|
||||
src: "/logos/chase.svg",
|
||||
},
|
||||
];
|
||||
|
||||
|
|
@ -28,14 +28,28 @@ export function LogoCloud() {
|
|||
return (
|
||||
<section className="relative py-6 sm:py-8 px-4 sm:px-6 lg:px-8">
|
||||
<div className="max-w-[81rem] mx-auto">
|
||||
<div className="grid grid-cols-2 md:grid-cols-3 lg:grid-cols-5 gap-4 sm:gap-6 md:gap-8 lg:gap-12 items-center justify-items-center">
|
||||
<div className="grid grid-cols-2 md:grid-cols-3 lg:flex lg:flex-row lg:justify-center lg:items-center gap-4 sm:gap-6 md:gap-8 lg:gap-0 place-items-center">
|
||||
{customerLogos.map((logo, index) => {
|
||||
const isLast = index === customerLogos.length - 1;
|
||||
const isTMobile = index === 1; // T-Mobile is before HP
|
||||
const isHP = index === 2; // HP is in center
|
||||
const isSanDisk = index === 3; // SanDisk is after HP
|
||||
|
||||
// Custom spacing for logos around HP on large screens
|
||||
let spacingClass = 'lg:mx-6 xl:mx-8'; // Default spacing
|
||||
if (isTMobile) {
|
||||
spacingClass = 'lg:mr-3 xl:mr-4 lg:ml-6 xl:ml-8'; // Smaller gap to HP
|
||||
} else if (isHP) {
|
||||
spacingClass = 'lg:mx-3 xl:mx-4'; // Smaller gaps on both sides
|
||||
} else if (isSanDisk) {
|
||||
spacingClass = 'lg:ml-3 xl:ml-4 lg:mr-6 xl:mr-8'; // Smaller gap from HP
|
||||
}
|
||||
|
||||
return (
|
||||
<div
|
||||
key={logo.name}
|
||||
className={`flex items-center justify-center opacity-60 hover:opacity-80 transition-opacity duration-300 w-full max-w-32 sm:max-w-40 md:max-w-48 h-10 sm:h-12 md:h-16 ${
|
||||
isLast ? "col-span-2 md:col-span-3 lg:col-span-1" : ""
|
||||
className={`flex items-center justify-center opacity-60 hover:opacity-80 transition-opacity duration-300 w-full max-w-32 sm:max-w-40 md:max-w-48 h-10 sm:h-12 md:h-16 mx-auto ${spacingClass} ${
|
||||
isLast ? "col-span-2 md:col-span-3 lg:col-span-none" : ""
|
||||
}`}
|
||||
>
|
||||
<Image
|
||||
|
|
|
|||
343
arch/tools/TESTING.md
Normal file
343
arch/tools/TESTING.md
Normal file
|
|
@ -0,0 +1,343 @@
|
|||
# Manual Testing & Development Guide for CLI
|
||||
|
||||
This guide explains how to manually test and develop the `archgw` CLI tool.
|
||||
|
||||
## Quick Start - Development Setup
|
||||
|
||||
### 1. Set Up Development Environment
|
||||
|
||||
From the `arch/tools` directory:
|
||||
|
||||
```bash
|
||||
# Create and activate virtual environment
|
||||
python -m venv venv
|
||||
source venv/bin/activate # On Mac/Linux
|
||||
# OR
|
||||
venv\Scripts\activate # On Windows
|
||||
|
||||
# Install dependencies in development mode
|
||||
poetry install
|
||||
```
|
||||
|
||||
### 2. Run CLI in Development Mode
|
||||
|
||||
You have two options to run the CLI during development:
|
||||
|
||||
#### Option A: Run directly with Python (Fastest for iteration)
|
||||
|
||||
```bash
|
||||
# From arch/tools directory
|
||||
python -m cli.main --help
|
||||
python -m cli.main build
|
||||
python -m cli.main up --path /path/to/config
|
||||
```
|
||||
|
||||
#### Option B: Install in editable mode (Recommended)
|
||||
|
||||
```bash
|
||||
# Install the package in editable/development mode
|
||||
pip install -e .
|
||||
|
||||
# Now you can use 'archgw' command directly
|
||||
archgw --help
|
||||
archgw build
|
||||
archgw up --path /path/to/config
|
||||
```
|
||||
|
||||
**Note**: After making changes to the code, you don't need to reinstall - changes are immediately available with editable install!
|
||||
|
||||
## Manual Testing Workflow
|
||||
|
||||
### Testing Individual Commands
|
||||
|
||||
Here's how to test each CLI command manually:
|
||||
|
||||
### 1. Test `build` Command
|
||||
|
||||
```bash
|
||||
# Test building the Docker image
|
||||
archgw build
|
||||
|
||||
# Or with Python directly
|
||||
python -m cli.main build
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Docker image builds successfully
|
||||
- No errors in output
|
||||
- Image is created with correct tag
|
||||
|
||||
### 2. Test `up` Command
|
||||
|
||||
```bash
|
||||
# Test with a config file path
|
||||
archgw up --path /path/to/demo/arch_config.yaml
|
||||
|
||||
# Test with explicit file
|
||||
archgw up /path/to/arch_config.yaml
|
||||
|
||||
# Test with foreground mode
|
||||
archgw up --path /path/to/config --foreground
|
||||
|
||||
# Test error case - non-existent file
|
||||
archgw up --path /nonexistent/path
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Config file is found correctly
|
||||
- Validation runs
|
||||
- Docker container starts
|
||||
- Health checks pass
|
||||
- Error messages are clear when things fail
|
||||
|
||||
### 3. Test `down` Command
|
||||
|
||||
```bash
|
||||
# Stop the gateway
|
||||
archgw down
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Container stops cleanly
|
||||
- No errors on shutdown
|
||||
|
||||
### 4. Test `logs` Command
|
||||
|
||||
```bash
|
||||
# View logs
|
||||
archgw logs
|
||||
|
||||
# Follow logs in real-time
|
||||
archgw logs --follow
|
||||
|
||||
# View debug logs
|
||||
archgw logs --debug --follow
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Logs are readable
|
||||
- Follow mode works correctly
|
||||
- Debug mode shows additional information
|
||||
|
||||
### 5. Test `generate_prompt_targets` Command
|
||||
|
||||
```bash
|
||||
# Generate targets from a Python file
|
||||
archgw generate-prompt-targets --f /path/to/your/file.py
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Targets are generated correctly
|
||||
- Output format is valid
|
||||
- Handles different Python function signatures
|
||||
|
||||
### 6. Test `cli_agent` Command
|
||||
|
||||
```bash
|
||||
# Start CLI agent (requires archgw to be running)
|
||||
archgw cli-agent claude --path /path/to/config
|
||||
|
||||
# With custom settings
|
||||
archgw cli-agent claude --path /path/to/config --settings '{"key": "value"}'
|
||||
```
|
||||
|
||||
**What to check:**
|
||||
- Agent connects to running gateway
|
||||
- Settings are passed correctly
|
||||
- Error handling when gateway isn't running
|
||||
|
||||
### 7. Test Version Command
|
||||
|
||||
```bash
|
||||
# Check version
|
||||
archgw --version
|
||||
```
|
||||
|
||||
## Development Tips
|
||||
|
||||
### Quick Iteration Cycle
|
||||
|
||||
1. **Make changes** to CLI code in `cli/` directory
|
||||
2. **Test immediately** - no reinstall needed with editable install:
|
||||
```bash
|
||||
python -m cli.main <command>
|
||||
# OR if installed
|
||||
archgw <command>
|
||||
```
|
||||
3. **Check output** and iterate
|
||||
|
||||
### Testing with Real Config Files
|
||||
|
||||
Use the demo configs in the repo:
|
||||
|
||||
```bash
|
||||
# From arch/tools directory
|
||||
cd ../../demos/samples_python/weather_forecast
|
||||
|
||||
# Test with this config
|
||||
archgw up arch_config.yaml
|
||||
|
||||
# Or test from tools directory
|
||||
archgw up ../../demos/samples_python/weather_forecast/arch_config.yaml
|
||||
```
|
||||
|
||||
### Debugging Tips
|
||||
|
||||
1. **Add print statements** for quick debugging:
|
||||
```python
|
||||
import sys
|
||||
print(f"DEBUG: Variable value: {variable}", file=sys.stderr)
|
||||
```
|
||||
|
||||
2. **Use Python debugger**:
|
||||
```python
|
||||
import pdb; pdb.set_trace()
|
||||
```
|
||||
|
||||
3. **Check Docker status** manually:
|
||||
```bash
|
||||
docker ps
|
||||
docker logs archgw
|
||||
docker inspect archgw
|
||||
```
|
||||
|
||||
4. **Test individual functions** in Python REPL:
|
||||
```bash
|
||||
python
|
||||
>>> from cli.utils import find_config_file
|
||||
>>> find_config_file(".", None)
|
||||
```
|
||||
|
||||
### Common Test Scenarios
|
||||
|
||||
#### Test Error Handling
|
||||
|
||||
```bash
|
||||
# Test missing config file
|
||||
archgw up --path /nonexistent
|
||||
|
||||
# Test invalid config file
|
||||
archgw up /path/to/invalid_config.yaml
|
||||
|
||||
# Test missing environment variables
|
||||
# (remove required env vars and test)
|
||||
archgw up --path /path/to/config
|
||||
```
|
||||
|
||||
#### Test Edge Cases
|
||||
|
||||
```bash
|
||||
# Test with minimal config
|
||||
archgw up --path /path/to/minimal_config.yaml
|
||||
|
||||
# Test with complex config
|
||||
archgw up --path /path/to/complex_config.yaml
|
||||
|
||||
# Test with different paths
|
||||
archgw up --path .
|
||||
archgw up --path /absolute/path
|
||||
archgw up relative/path/config.yaml
|
||||
```
|
||||
|
||||
## Example: Testing a Specific Feature
|
||||
|
||||
Let's say you're working on improving the `find_config_file` function. Here's how to test it:
|
||||
|
||||
```bash
|
||||
# Start Python REPL
|
||||
python
|
||||
|
||||
# Import and test
|
||||
>>> from cli.utils import find_config_file
|
||||
>>> import os
|
||||
>>> find_config_file(".", None)
|
||||
'/absolute/path/to/arch/tools/arch_config.yaml'
|
||||
|
||||
# Test with explicit file
|
||||
>>> find_config_file(".", "/path/to/config.yaml")
|
||||
'/path/to/config.yaml'
|
||||
|
||||
# Test error cases
|
||||
>>> find_config_file("/nonexistent", None)
|
||||
# Check what happens
|
||||
```
|
||||
|
||||
## File Structure Reference
|
||||
|
||||
When developing, you'll primarily work with:
|
||||
|
||||
- `cli/main.py` - Main CLI commands and entry point
|
||||
- `cli/core.py` - Core functionality (start_arch, stop_docker_container, etc.)
|
||||
- `cli/utils.py` - Utility functions
|
||||
- `cli/docker_cli.py` - Docker-related operations
|
||||
- `cli/config_generator.py` - Config validation and generation
|
||||
- `cli/targets.py` - Prompt target generation
|
||||
- `cli/consts.py` - Constants
|
||||
|
||||
## Quick Reference: Common Commands
|
||||
|
||||
```bash
|
||||
# Setup (one time)
|
||||
cd arch/tools
|
||||
python -m venv venv
|
||||
source venv/bin/activate
|
||||
poetry install
|
||||
pip install -e . # For editable install
|
||||
|
||||
# Development workflow
|
||||
# 1. Edit code in cli/*.py
|
||||
# 2. Test immediately:
|
||||
python -m cli.main <command> [args]
|
||||
|
||||
# Or if installed:
|
||||
archgw <command> [args]
|
||||
|
||||
# Common test commands:
|
||||
archgw --version # Check version
|
||||
archgw --help # See all commands
|
||||
archgw build # Build Docker image
|
||||
archgw up --path /path/to/config # Start gateway
|
||||
archgw down # Stop gateway
|
||||
archgw logs --follow # View logs
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### CLI command not found
|
||||
- Make sure you activated the virtual environment
|
||||
- If using editable install, verify: `pip list | grep archgw`
|
||||
- Try: `python -m cli.main` instead
|
||||
|
||||
### Changes not reflected
|
||||
- If using editable install, changes should be immediate
|
||||
- If not, reinstall: `pip install -e .`
|
||||
- Check you're editing the right file
|
||||
|
||||
### Docker issues
|
||||
- Ensure Docker is running: `docker ps`
|
||||
- Check container status: `docker ps -a | grep archgw`
|
||||
- View logs: `docker logs archgw`
|
||||
|
||||
## Finding Demo Configs to Test With
|
||||
|
||||
The repository has several demo configs you can use for testing:
|
||||
|
||||
```bash
|
||||
# List available demos
|
||||
ls ../../demos/samples_python/*/arch_config.yaml
|
||||
|
||||
# Examples:
|
||||
# - ../../demos/samples_python/weather_forecast/arch_config.yaml
|
||||
# - ../../demos/samples_python/currency_exchange/arch_config.yaml
|
||||
# - ../../demos/samples_python/human_resources_agent/arch_config.yaml
|
||||
```
|
||||
|
||||
## Tips for Effective Manual Testing
|
||||
|
||||
1. **Test one thing at a time** - Make a small change, test it, then move on
|
||||
2. **Test both success and failure cases** - Don't just test happy paths
|
||||
3. **Use real configs** - Test with actual demo configs to catch real-world issues
|
||||
4. **Check error messages** - Make sure error messages are helpful
|
||||
5. **Test edge cases** - Empty files, missing fields, invalid values
|
||||
6. **Keep notes** - Document what works and what doesn't as you develop
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue