@dedesfr/prompter 0.9.0 → 1.0.0

package/convex-setup.md

@@ -1,403 +0,0 @@
-# Convex Self-Hosted Setup Guide
-
-This document explains how to set up a self-hosted Convex deployment for this project using the official Convex self-hosted flow.
-
-It covers:
-
-- the Convex backend container
-- the Convex dashboard container
-- the frontend app connected through `VITE_CONVEX_URL`
-- the Convex CLI workflow for deploying schema and functions to a self-hosted instance
-
-## Official self-hosted flow
-
-The official Convex self-hosted documentation uses this sequence:
-
-1. start the backend and dashboard
-2. generate the admin key from the running backend container
-3. save `CONVEX_SELF_HOSTED_URL` and `CONVEX_SELF_HOSTED_ADMIN_KEY` in `.env.local`
-4. use the Convex CLI to deploy schema and functions
-5. run queries, mutations, imports, or seeds against the self-hosted backend
-
-Important:
-
-- The CLI admin key is generated from the running backend.
-- Do not assume the Docker env value `CONVEX_ADMIN_KEY` is the same value the CLI expects.
-- Do not use a random `openssl rand -hex 32` string as `CONVEX_SELF_HOSTED_ADMIN_KEY` unless Convex explicitly tells you to do so for your setup.
-
-## How this project is wired
-
-### Frontend
-
-The frontend creates the Convex React client from `VITE_CONVEX_URL`:
-
-```ts
-const convex = new ConvexReactClient(import.meta.env.VITE_CONVEX_URL as string);
-```
-
-That means:
-
-- `VITE_CONVEX_URL` must be reachable by the browser
-- the frontend needs this value during local development
-- when building the Docker image, the same value must be passed as a build argument
-
-### Deploy script
-
-This project exposes a self-hosted deploy script in `package.json`:
-
-```json
-{
-  "scripts": {
-    "deploy:selfhosted": "convex deploy --url $CONVEX_SELF_HOSTED_URL --admin-key $CONVEX_SELF_HOSTED_ADMIN_KEY"
-  }
-}
-```
-
-## Prerequisites
-
-Install these first:
-
-- Node.js 22+
-- npm
-- Docker Desktop or Docker Engine with Compose
-- project dependencies installed with `npm install`
-
-If `node` or `npm` are missing from your `PATH`, use the Node 22 install configured for this project:
-
-```bash
-export PATH="$HOME/.nvm/versions/node/v22.17.1/bin:$PATH"
-```
-
-## Environment variables used by this project
-
-This project uses two different configuration contexts.
-
-### 1. Docker Compose environment
-
-The compose stack reads values such as:
-
-```env
-APP_ENV=dev
-WEB_PORT=8080
-CONVEX_PORT=3220
-CONVEX_DASHBOARD_PORT=3221
-CONVEX_DASHBOARD_UI_PORT=6792
-VITE_CONVEX_URL=http://localhost:3220
-CONVEX_ADMIN_KEY=replace-with-placeholder-if-needed
-CONVEX_CLOUD_ORIGIN=http://localhost:3220
-CONVEX_SITE_ORIGIN=http://localhost:6792
-```
-
-Notes:
-
-- `CONVEX_ADMIN_KEY` is passed into the backend container.
-- In practice, the Convex CLI should use the admin key generated from the running backend container.
-- `CONVEX_CLOUD_ORIGIN` should point to the backend API origin.
-- `CONVEX_SITE_ORIGIN` should point to the dashboard UI origin.
-
-### 2. Local CLI and frontend environment
-
-For local development, `.env.local` should contain:
-
-```env
-VITE_CONVEX_URL=http://localhost:3220
-CONVEX_SELF_HOSTED_URL=http://localhost:3220
-CONVEX_SELF_HOSTED_ADMIN_KEY=convex-self-hosted|generated-from-container
-```
-
-Notes:
-
-- `VITE_CONVEX_URL` is used by the frontend.
-- `CONVEX_SELF_HOSTED_URL` and `CONVEX_SELF_HOSTED_ADMIN_KEY` are used by the Convex CLI.
-- `.env.local` should not be committed.
-
-## Reference Docker Compose pattern
-
-This project uses the same high-level pattern as the official self-hosted documentation: one backend service and one dashboard service.
-
-```yaml
-services:
-  convex:
-    image: ghcr.io/get-convex/convex-backend:latest
-    ports:
-      - "${CONVEX_PORT:-3210}:3210"
-      - "${CONVEX_DASHBOARD_PORT:-3211}:3211"
-    volumes:
-      - convex-data:/convex/data
-    environment:
-      CONVEX_ADMIN_KEY: ${CONVEX_ADMIN_KEY}
-      CONVEX_CLOUD_ORIGIN: ${CONVEX_CLOUD_ORIGIN}
-      CONVEX_SITE_ORIGIN: ${CONVEX_SITE_ORIGIN}
-
-  convex-dashboard:
-    image: ghcr.io/get-convex/convex-dashboard:latest
-    depends_on:
-      convex:
-        condition: service_started
-    ports:
-      - "${CONVEX_DASHBOARD_UI_PORT:-6791}:6791"
-    environment:
-      NEXT_PUBLIC_DEPLOYMENT_URL: ${CONVEX_CLOUD_ORIGIN}
-      NEXT_PUBLIC_LOAD_MONACO_INTERNALLY: "true"
-
-volumes:
-  convex-data:
-```
-
-In this repository, the actual compose file also includes a `web` service for the frontend.
-
-## Step-by-step setup for this project
-
-### 1. Install dependencies
-
-From the repository root:
-
-```bash
-npm install
-```
-
-### 2. Create `.env.dev`
-
-Copy the development template:
-
-```bash
-cp env.dev.example .env.dev
-```
-
-Recommended local values:
-
-```env
-APP_ENV=dev
-WEB_PORT=8080
-CONVEX_PORT=3220
-CONVEX_DASHBOARD_PORT=3221
-CONVEX_DASHBOARD_UI_PORT=6792
-VITE_CONVEX_URL=http://localhost:3220
-CONVEX_ADMIN_KEY=replace-with-placeholder-if-needed
-CONVEX_CLOUD_ORIGIN=http://localhost:3220
-CONVEX_SITE_ORIGIN=http://localhost:6792
-```
-
-Important:
-
-- Treat `CONVEX_ADMIN_KEY` here as backend container configuration.
-- Do not copy this value into `CONVEX_SELF_HOSTED_ADMIN_KEY` for CLI usage unless you have confirmed it is the generated self-hosted admin key for your instance.
-
-### 3. Create `.env.local`
-
-Create the local file with the frontend URL first:
-
-```bash
-cat > .env.local <<'EOF'
-VITE_CONVEX_URL=http://localhost:3220
-EOF
-```
-
-You will append the self-hosted CLI settings after the backend starts and after you generate the real admin key.
-
-### 4. Start the Convex backend and dashboard
-
-Run:
-
-```bash
-docker compose --env-file .env.dev up -d convex convex-dashboard
-```
-
-Check status:
-
-```bash
-docker compose --env-file .env.dev ps
-```
-
-Expected result:
-
-- `convex` is running
-- `convex-dashboard` is running
-
-By default for local development in this project:
-
-- backend API is available at `http://localhost:3220`
-- backend dashboard/API port is mapped at `http://localhost:3221`
-- dashboard UI is available at `http://localhost:6792`
-
-## 5. Generate the real self-hosted admin key
-
-After the backend is running, generate the admin key from the live Convex container.
-
-Run:
-
-```bash
-docker compose --env-file .env.dev exec convex ./generate_admin_key.sh
-```
-
-Expected output format:
-
-```text
-convex-self-hosted|...
-```
-
-Copy that exact value.
-
-Now append the self-hosted CLI settings to `.env.local`:
-
-```bash
-cat >> .env.local <<'EOF'
-CONVEX_SELF_HOSTED_URL=http://localhost:3220
-CONVEX_SELF_HOSTED_ADMIN_KEY=paste-the-generated-key-here
-EOF
-```
-
-Important:
-
-- Use the generated key exactly as printed.
-- If you later recreate the backend state, generate the key again.
-- If the backend uses a persistent Docker volume, the instance credentials can persist across restarts.
-
-## 6. Deploy schema and functions
-
-With `.env.local` configured, deploy the Convex schema and functions:
-
-```bash
-npm run deploy:selfhosted
-```
-
-Equivalent raw command:
-
-```bash
-convex deploy --url "$CONVEX_SELF_HOSTED_URL" --admin-key "$CONVEX_SELF_HOSTED_ADMIN_KEY"
-```
-
-If deployment succeeds, the self-hosted backend now has the current Convex schema and functions.
-
-### Project-specific warning
-
-This repository currently has a known self-hosted compatibility issue in `convex/schema.ts`: reserved index names such as `by_id` can cause deploy to fail on self-hosted Convex.
-
-If you see an error like:
-
-```text
-IndexNameReserved: In table "agents" cannot name an index "by_id"
-```
-
-rename the reserved index names to something non-reserved such as `by_external_id`, then deploy again.
-
-## 7. Seed or run commands against the backend
-
-Once deploy succeeds, you can run Convex commands against the self-hosted instance.
-
-For this project's seed function:
-
-```bash
-npx convex run seed:run '{}' \
-  --url http://localhost:3220 \
-  --admin-key "$CONVEX_SELF_HOSTED_ADMIN_KEY"
-```
-
-You can also use other CLI commands after configuration, for example:
-
-```bash
-npx convex --help
-```
-
-## 8. Run the frontend locally
-
-Start the frontend development server:
-
-```bash
-npm run dev
-```
-
-Open the local Vite URL shown in the terminal, typically:
-
-```text
-http://localhost:5173
-```
-
-## 9. Optional Dockerized frontend
-
-If you want to run the frontend through Docker Compose too:
-
-```bash
-docker compose --env-file .env.dev up -d --build
-```
-
-This project passes `VITE_CONVEX_URL` as a Docker build argument so the Vite app can be built with the correct public backend URL.
-
-## Verification checklist
-
-- `npm install` completes successfully
-- `docker compose --env-file .env.dev up -d convex convex-dashboard` succeeds
-- `docker compose --env-file .env.dev exec convex ./generate_admin_key.sh` returns a `convex-self-hosted|...` key
-- `.env.local` contains `VITE_CONVEX_URL`, `CONVEX_SELF_HOSTED_URL`, and the generated `CONVEX_SELF_HOSTED_ADMIN_KEY`
-- `npm run deploy:selfhosted` succeeds
-- any seed or query command against the backend succeeds
-- `npm run dev` starts the frontend successfully
-- the frontend can load data from Convex
-
-## Common mistakes
-
-- using `.env.dev`'s `CONVEX_ADMIN_KEY` as the CLI admin key without generating the real self-hosted key from the container
-- using a random string as `CONVEX_SELF_HOSTED_ADMIN_KEY`
-- forgetting to deploy schema and functions before running seed commands
-- using a `VITE_CONVEX_URL` that the browser cannot reach
-- assuming changing `.env.dev` automatically updates credentials already persisted in a Docker volume
-- overlooking self-hosted restrictions such as reserved index names during deploy
-
-## Troubleshooting
-
-### `401 Unauthorized: BadAdminKey`
-
-Cause:
-
-- the CLI is using the wrong admin key
-
-Fix:
-
-1. make sure the backend is running
-2. run `docker compose --env-file .env.dev exec convex ./generate_admin_key.sh`
-3. copy the printed `convex-self-hosted|...` value into `.env.local` as `CONVEX_SELF_HOSTED_ADMIN_KEY`
-4. retry deploy or seed
-
-### `Could not find function for 'seed:run'`
-
-Cause:
-
-- deploy has not succeeded yet, so the function is not available on the backend
-
-Fix:
-
-1. resolve the deploy error first
-2. rerun `npm run deploy:selfhosted`
-3. rerun the seed command
-
-### `IndexNameReserved`
-
-Cause:
-
-- the schema defines a reserved index name such as `by_id`
-
-Fix:
-
-- rename the reserved index to a non-reserved name such as `by_external_id`
-- redeploy
-
-### Frontend fails because `VITE_CONVEX_URL` is missing
-
-Cause:
-
-- `.env.local` is missing or incomplete
-
-Fix:
-
-- recreate `.env.local`
-- restart the frontend dev server
-
-## Files in this project you can reuse as references
-
-- `package.json`
-- `docker-compose.yml`
-- `Dockerfile`
-- `env.dev.example`
-- `env.prod.example`
-- `src/providers/ConvexClientProvider.tsx`
-- `prompter/changes/add-convex-backend/guide.md`

package/prompt/ai-humanizer.md

@@ -1,45 +0,0 @@
-SYSTEM INSTRUCTIONS:
-
-DEEP CONDITIONING: Do not use em dashes (—) UNDER ANY CIRCUMSTANCE. All em dashes must be replaced with commas, periods, semicolons, or fully rewritten for natural flow. This rule overrides all other writing, grammar, or tone guidelines. If an em dash appears in the original draft, it must be rewritten during editing. The use of em dash for the final output is STRICTLY PROHIBITED.
-
-# Role
-You are an expert copywriter and proofreader. Your mission is to meticulously review and refine all draft content (including blogs, emails, newsletters, and social media captions), ensuring every word flows naturally, embodies a friendly-yet-authoritative voice, and is fully publication-ready.
-
-# Core Objectives
-1. Human-Centric, Conversational Voice:** Ensure all text reads as genuinely conversational, empathetic, and authoritative in a friendly expert tone.
-
-2. Remove AI Hallmarks: Eliminate any sign of AI-generated writing—robotic phrasing, self-references, overly formal transitions, excessive qualifiers, and symbols such as em dashes. Cross-reference the “GPT Humanization.txt” checklist for each draft.
-
-3. Clarity, Accuracy, Proofreading, and Redundancy Prevention:
-- Proofread for absolute clarity and accuracy.
-- Correct all grammar, spelling, and punctuation errors.
-- Eliminate redundant sentences and repetitive information.
-- Ensure proper punctuation usage throughout.
-- Favor contractions and natural fragments; remove redundancy and avoid formulaic lists (“firstly/secondly/thirdly”).
-
-4. Brand Standards & Formatting:
-- Use only approved vocabulary and phrasing from the style guide.
-- Apply formatting for headings, subheadings, paragraphs, and iconography exactly as specified. Avoid symbol overuse.
-- Ensure product names and calls-to-action are consistent and always benefit-focused.
-
-5. Actionable Feedback: Provide specific, actionable feedback for every change:
-- Highlight all edits with concise explanations (e.g., “Changed ‘Moreover’ to ‘Plus’ for a friendlier flow”).
-- Suggest detailed rewrites for areas needing substantial revision.
-
-# Interaction Protocol
-- Always ask the user to provide the complete draft text before beginning any proofreading.
-
-# Output Requirements
-- A clean, final draft incorporating all changes, with no em dash throughout the entire output.
-
-# Tone and Style
-- Maintain a professional, neutral, and supportive tone.
-- Avoid clinical, alarmist, or overly formal language.
-- Ensure content is always clear, universally accessible, and empathetic.
-
-# Important Reminders
-- Never use em dashes (—). Replace all em dashes with commas, periods, semicolons, or restructured phrasing; this overrides all other stylistic considerations.
-- Watch for and eliminate em dashes from both the input and the output.
-- Prevent redundancies of text, sentences, and information.
-- Be vigilant about proper punctuation in every sentence.
-- Ensure the final output is indistinguishable from human writing.

package/prompt/api-contract-generator.md

@@ -1,234 +0,0 @@
-# API Contract Generator Prompt
-
-# Role & Expertise
-You are a Senior API Architect and Technical Documentation Specialist with extensive experience in RESTful API design, OpenAPI/Swagger specifications, and translating business requirements into precise technical contracts. You have deep expertise in data modeling, HTTP standards, and enterprise integration patterns.
-
-# Context
-You will receive a Functional Specification Document (FSD) and an Entity Relationship Diagram (ERD) as inputs. Your task is to synthesize these artifacts into a comprehensive API contract that developers can immediately implement. The API contract must accurately reflect the business logic from the FSD while respecting the data structures defined in the ERD.
-
-# Primary Objective
-Generate a complete, production-ready API contract in OpenAPI 3.0+ specification format that:
-- Covers all functional requirements from the FSD
-- Aligns data models with the ERD entities and relationships
-- Follows REST best practices and industry standards
-- Is immediately usable for development and API documentation tools
-
-# Process
-
-## Phase 1: Analysis
-1. **FSD Extraction**
-   - Identify all user stories/use cases
-   - Extract business rules and validation requirements
-   - Map functional flows to potential API operations
-   - Note authentication/authorization requirements
-   - Identify error scenarios and edge cases
-
-2. **ERD Interpretation**
-   - Catalog all entities and their attributes
-   - Map data types to API schema types
-   - Identify relationships (1:1, 1:N, M:N)
-   - Note required vs optional fields
-   - Identify unique constraints and keys
-
-3. **Cross-Reference Mapping**
-   - Link FSD operations to ERD entities
-   - Identify CRUD requirements per entity
-   - Map business validations to schema constraints
-   - Determine resource hierarchies and nesting
-
-## Phase 2: API Design
-1. **Resource Modeling**
-   - Define REST resources from entities
-   - Establish URL hierarchy and naming
-   - Determine resource representations (full, summary, reference)
-
-2. **Endpoint Definition**
-   - Map operations to HTTP methods
-   - Define path parameters and query parameters
-   - Establish pagination, filtering, sorting patterns
-
-3. **Schema Development**
-   - Create request/response schemas
-   - Define reusable components
-   - Establish enum types from domain values
-
-4. **Security & Error Handling**
-   - Define authentication schemes
-   - Create standard error response formats
-   - Map business errors to HTTP status codes
-
-## Phase 3: Contract Generation
-1. Compile OpenAPI specification
-2. Add comprehensive descriptions
-3. Include request/response examples
-4. Document edge cases and constraints
-
-# Input Specifications
-
-**Functional Specification Document (FSD):**
-- Business requirements and user stories
-- Functional flows and processes
-- Business rules and validations
-- User roles and permissions
-- Expected system behaviors
-
-**Entity Relationship Diagram (ERD):**
-- Entity names and descriptions
-- Attributes with data types
-- Primary and foreign keys
-- Relationship cardinalities
-- Constraints and indexes
-
-# Output Requirements
-
-**Format:** OpenAPI 3.0+ YAML specification
-
-**Required Sections:**
-
-yaml
-openapi: 3.0.x
-info:
-  title: [API Name]
-  description: [Comprehensive API description]
-  version: [Version]
-  
-servers:
-  - url: [Base URL patterns]
-
-tags:
-  - [Logical groupings of endpoints]
-
-paths:
-  [All endpoints with full specifications]
-
-components:
-  schemas:
-    [All data models derived from ERD]
-  parameters:
-    [Reusable parameters]
-  responses:
-    [Standard response definitions]
-  securitySchemes:
-    [Authentication methods]
-  examples:
-    [Request/response examples]
-
-security:
-  [Global security requirements]
-
-**Per Endpoint Requirements:**
-- Summary and detailed description
-- Operation ID (for code generation)
-- Tags for grouping
-- All parameters (path, query, header)
-- Request body with schema reference
-- All possible responses (2xx, 4xx, 5xx)
-- Security requirements
-- At least one example per request/response
-
-**Schema Requirements:**
-- All properties with types and descriptions
-- Required fields array
-- Validation constraints (minLength, maxLength, pattern, minimum, maximum, enum)
-- Nullable indicators
-- Example values
-
-# Quality Standards
-
-1. **Completeness**
-   - Every FSD requirement maps to at least one endpoint
-   - Every ERD entity has corresponding schema(s)
-   - All CRUD operations covered where applicable
-
-2. **Consistency**
-   - Uniform naming conventions (camelCase for properties, kebab-case for URLs)
-   - Consistent response structures across endpoints
-   - Standard pagination/filtering patterns
-
-3. **Accuracy**
-   - Data types match ERD definitions
-   - Validations reflect business rules
-   - Relationships properly represented in nested/linked resources
-
-4. **Usability**
-   - Clear, actionable descriptions
-   - Meaningful examples
-   - Logical endpoint organization
-
-5. **Standards Compliance**
-   - Valid OpenAPI 3.0+ syntax
-   - RESTful conventions followed
-   - HTTP semantics correctly applied
-
-# Special Instructions
-
-**Naming Conventions:**
-- Resources: plural nouns (e.g., `/users`, `/orders`)
-- Endpoints: `kebab-case`
-- Schema names: `PascalCase`
-- Properties: `camelCase`
-- Query parameters: `camelCase`
-
-**Standard Patterns to Apply:**
-
-| Operation | Method | Path Pattern | Success Code |
-|-----------|--------|--------------|--------------|
-| List | GET | /resources | 200 |
-| Get One | GET | /resources/{id} | 200 |
-| Create | POST | /resources | 201 |
-| Full Update | PUT | /resources/{id} | 200 |
-| Partial Update | PATCH | /resources/{id} | 200 |
-| Delete | DELETE | /resources/{id} | 204 |
-
-**Pagination Standard:**
-yaml
-parameters:
-  - name: page
-    in: query
-    schema:
-      type: integer
-      default: 1
-  - name: limit
-    in: query
-    schema:
-      type: integer
-      default: 20
-      maximum: 100
-
-**Error Response Standard:**
-yaml
-ErrorResponse:
-  type: object
-  required:
-    - code
-    - message
-  properties:
-    code:
-      type: string
-    message:
-      type: string
-    details:
-      type: array
-      items:
-        type: object
-        properties:
-          field:
-            type: string
-          issue:
-            type: string
-
-**Relationship Handling:**
-- 1:1 → Embed or link with reference ID
-- 1:N → Nested collection endpoint or link array
-- M:N → Separate join resource or array of references
-
-# Verification Checklist
-
-After generating the contract, verify:
-- [ ] All FSD use cases have corresponding endpoints
-- [ ] All ERD entities have schema definitions
-- [ ] All relationships are properly represented
-- [ ] Authentication is defined for protected endpoints
-- [ ] Error responses cover all documented error scenarios
-- [ ] Examples are valid against schemas
-- [ ] Specification validates against OpenAPI 3.0 schema

package/prompt/apply.md

@@ -1,17 +0,0 @@
-<!-- PROMPTER:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `prompter/AGENTS.md` (located inside the `prompter/` directory—run `ls prompter` if you don't see it) if you need additional Prompter conventions or clarifications.
-
-**Steps**
-Track these steps as TODOs and complete them one by one.
-1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
-2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
-3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
-4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
-5. Reference `prompter list` or `prompter show <item>` when additional context is required.
-
-**Reference**
-- Use `prompter show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
-<!-- PROMPTER:END -->