Project Implementation Plan

You are an expert software engineer. Implement the following project carefully, with minimal errors, following the plan, stack, and standards below. Ask clarifying questions only if truly necessary; otherwise proceed.

1. Project Overview

• Name: Prompt-library-with-evaluation-a-web-app
• Description: Prompt library with evaluation: a web app + CLI to store versioned prompts with {{variables}}, attach test cases (input/expected), and run A/B comparisons across multiple LLM backends (OpenAI, Anthropic, Ollama). Tracks cost, latency, and pass rate per version. Export winning prompts as a bundle for the hub. Helps teams stop losing their best prompts in chat history.
• Type: cli
• Audience: developers
• Scale: small
• Created: 2026-10-28T20:33:11.236078278+00:00

2. Requirements

• project_type: cli
• database: none
• auth: none
• deployment: local
• scale: small
• feature: Prompt library with evaluation: a web app + CLI to store versioned prompts with {{variables}}
• feature: attach test cases
• feature: and run A/B comparisons across multiple LLM backends . Tracks cost
• feature: run command

3. Chosen Stack

• Language: Rust
• Libraries: clap, serde, toml, serde_json, tar, flate2, walkdir, reqwest, self_update, sha2, tempfile, dirs, tracing
• Rationale: Rust chosen for cli project (scale: small).

4. Libraries (details)

• clap (rust, cli): Command-line argument parsing — derive macros
• serde (rust, serialization): Serialize/deserialize — derive
• toml (rust, serialization): TOML parsing
• serde_json (rust, serialization): JSON serialization
• tar (rust, archive): Tar archiving
• flate2 (rust, compression): Gzip compression
• walkdir (rust, filesystem): Directory traversal
• reqwest (rust, http-client): HTTP client
• self_update (rust, update): Self-updating binaries — optional
• sha2 (rust, crypto): SHA-2 hashing
• tempfile (rust, filesystem): Temp files
• dirs (rust, filesystem): User directories
• tracing (rust, observability): Structured logging/tracing

5. Architecture

Single binary CLI. Flow: main -> cli (clap) -> command dispatch -> domain logic -> io. Modules: main, cli, config, manifest, pack, hub, update, error, io. Use anyhow at boundaries, thiserror in library code. Keep main thin; all logic in lib/testable modules.

6. Suggested File Structure

• Cargo.toml
• README.md
• src/main.rs
• src/cli.rs
• src/config.rs
• src/error.rs
• src/manifest.rs
• src/pack.rs
• src/hub.rs
• src/update.rs
• tests/cli.rs

7. Feature Plan

• Prompt library with evaluation: a web app + CLI to store versioned prompts with {{variables}}
• attach test cases
• and run A/B comparisons across multiple LLM backends . Tracks cost
• run command

8. Implementation Plan (Milestones)

M0: Setup — Scaffold

• [ ] M0-1 Scaffold: cargo init + tooling

M1: Manifest — Parse notdouble.toml

• [ ] M1-1 Manifest struct: serde + validation

M2: Pack — tar.gz

• [ ] M2-1 File collection: walkdir + ignore rules (depends on: M1-1)
• [ ] M2-2 Tar+gzip: tar + flate2, deterministic order (depends on: M2-1)

M3: Hub client — HTTP

• [ ] M3-1 Upload/download: reqwest multipart (depends on: M2-2)

M4: Commands — CLI commands

• [ ] M4-1 init/validate/upload: core commands (depends on: M3-1)
• [ ] M4-2 download/search/info: read commands (depends on: M3-1)

M5: Self-update — Update binary

• [ ] M5-1 self_update: checksum verify + rollback (depends on: M4-1)

M-Final: Polish — Docs/tests

• [ ] MF-1 Docs & tests: README, integration tests

9. Coding Standards

• Use strict typing; avoid any/unwrap in production paths.
• Handle errors explicitly; no silent failures.
• Add unit tests for core logic; integration tests for boundaries.
• Keep functions small; single responsibility.
• Document public API.
• Run cargo fmt, clippy; fix all warnings.
• Prefer anyhow for app errors, thiserror for library errors.

10. Risks & Mitigations

• Tar path traversal
• Secret leakage in bundles
• Self-update supply chain
• Hub API drift
• Unstable --json output
• Version conflicts
• Non-deterministic packaging

Common Pitfalls

• Tar traversal
• .git inclusion
• Non-deterministic archive ordering
• Self-update supply chain
• Hub API drift
• Unstable --json
• Secret leakage

11. Template Used

• cli-tool

Language Guidance

Rust Project Guidance

Project Layout

• Prefer a workspace for multi-crate projects.
• Binary crate: src/main.rs thin; logic in src/lib.rs or modules.
• Library crate: src/lib.rs public API; internal modules private.
• Tests: tests/ integration; unit tests co-located.

Error Handling

• Libraries: define enum Error with thiserror.
• Applications: use anyhow::Result at boundaries.
• Avoid unwrap()/expect() in production.

Design Patterns

• Newtype, Builder, trait objects, From/Into, Default, enum state machines, RAII/Drop, interior mutability.

Async

• Use tokio; avoid blocking in async; use spawn_blocking; channels for message passing.

Testing

• Unit + integration; property tests with proptest.

Tooling

• cargo fmt, clippy, test, doc, audit, deny.

Common Crates

• CLI: clap, dialoguer, indicatif, console, tracing.
• Web: axum, actix-web, reqwest, tower, tower-http.
• DB: sqlx, diesel, sea-orm.
• Errors: thiserror, anyhow, miette.
• Testing: proptest, mockall, wiremock, assert_cmd.

Domain

• web

Domain Guidance

Web Application Domain

Approach

• Separate routing, handlers, services, repositories.
• Validate all input at the boundary; never trust client data.
• Use middleware for auth, logging, CORS, rate limiting.
• Database migrations versioned; connection pooling.
• Server-rendered or SPA with clear API contract.

Common Patterns

• REST resource controllers (CRUD).
• JWT/session auth with refresh tokens.
• Repository pattern over SQL.
• Background jobs / queues.
• WebSocket for realtime; SSE for one-way.

Testing

• Unit: services, repositories (test DB).
• Integration: HTTP endpoints (supertest/axum-test).
• E2E: Playwright/Cypress.
• Load: k6/vegeta.

Pitfalls

• N+1 queries, missing indexes.
• CSRF/XSS on server-rendered apps.
• File upload abuse (size/type/path traversal).
• Session fixation, weak passwords.
• CORS misconfiguration.
• Rate limiting gaps on public endpoints. "

Final Instructions to the LLM

1. Follow the milestones in order; do not skip setup.
2. Use ONLY the chosen stack and libraries unless a strong reason exists; explain deviations.
3. Produce complete, runnable code for each file in the suggested structure.
4. Include tests for core logic.
5. Handle errors and edge cases; no panics in production paths.
6. End with a short summary of what was implemented and how to run it.