RADAAR

Build a personal replacement for RADAAR in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and exactly one official social-platform API; do not offer alternative stacks.
The core loop is: create, schedule, preview, publish, and track posts for one social network with a searchable content calendar.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Support drafts, scheduled posts, queues, campaigns, tags, reusable snippets, and a weekly calendar.
Connect exactly one social platform using its documented OAuth flow.
Validate character, media, aspect-ratio, and file-size limits before scheduling.
Publish through idempotent background jobs with retries and clear failure states.
Store platform post identifiers and refresh publication status through the official API.
Maintain a reusable media library with local storage.
Support CSV export and token reconnect.
Include clear empty, loading, success, and recoverable error states.
Add robust validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for scheduling logic and one end-to-end publishing flow.
Create a README covering setup, architecture, permissions, data storage, and backup.
Do not add billing, telemetry, hosted infrastructure, enterprise collaboration, social inbox, listening, analytics dashboards, white-labeling, or unofficial scraping.
Finish by running the tests and listing the exact commands used.

# AGENTS.md — Build guide for RADAAR

## Project scope
Schedule posts for one social platform, publish through the official API, manage a simple content calendar, and maintain reusable media assets.

Catalogue verdict: no. A basic scheduler can be recreated, but RADAAR's complete product · publishing, engagement, monitoring, analytics, team collaboration, asset management, approval workflows, and multi-network integrations · is not realistically replaceable in a weekend.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- developer application for one social platform
- OAuth credentials
- MySQL
- Redis
- background worker
- job queue
- cloud object storage

## Stack and architecture
- Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and exactly one official social-platform API.
- Model sources or channels, posts, dated observations, drafts, and reports; keep stable source IDs and timestamps.
- Interface for this social media management platform workflow: a local web page with input, progress, review, and export views.

## Security and data integrity
- Publish through idempotent background jobs with retries and clear failure states.
- Keep API keys and OAuth secrets in .env; redact them from logs, generated files, and error responses.
- State the practical limit: multi-network publishing.

## Agent implementation rules
- Project rule, data: Model sources or channels, posts, dated observations, drafts, and reports; keep stable source IDs and timestamps.
- Project rule, behavior: Support drafts, scheduled posts, queues, campaigns, tags, reusable snippets, and a weekly calendar.
- Project rule, recovery: Publish through idempotent background jobs with retries and clear failure states.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this social media management platform operation with sample or user-owned data: Support drafts, scheduled posts, queues, campaigns, tags, reusable snippets, and a weekly calendar.
- Show a concrete result or export: Support CSV export and token reconnect.
- State the practical limit: multi-network publishing.

## Engineering roadmap
1. Phase 1, architecture and data: Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and exactly one official social-platform API. Model sources or channels, posts, dated observations, drafts, and reports; keep stable source IDs and timestamps.
2. Phase 2, implement: Support drafts, scheduled posts, queues, campaigns, tags, reusable snippets, and a weekly calendar.
3. Phase 3, implement: Connect exactly one social platform using its documented OAuth flow.
4. Phase 4, review and output: Publish through idempotent background jobs with retries and clear failure states. Support CSV export and token reconnect.
5. Phase 5, recovery and acceptance: Publish through idempotent background jobs with retries and clear failure states. Verify this invariant with a saved fixture: An API gap must be labelled missing; a replayed export cannot double-count the same observation. State the practical limit: multi-network publishing.

## Paid-product capabilities outside this build
- multi-network publishing
- social inbox and engagement
- social listening and keyword monitoring
- advanced analytics and reporting
- approval workflows
- team collaboration
- workspace management
- media library
- URL shortener and tracking
- AI-assisted content workflows
- API ecosystem
- reliable hosted infrastructure

## Implementation prompt
Build a personal replacement for RADAAR in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and exactly one official social-platform API; do not offer alternative stacks.
The core loop is: create, schedule, preview, publish, and track posts for one social network with a searchable content calendar.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Support drafts, scheduled posts, queues, campaigns, tags, reusable snippets, and a weekly calendar.
Connect exactly one social platform using its documented OAuth flow.
Validate character, media, aspect-ratio, and file-size limits before scheduling.
Publish through idempotent background jobs with retries and clear failure states.
Store platform post identifiers and refresh publication status through the official API.
Maintain a reusable media library with local storage.
Support CSV export and token reconnect.
Include clear empty, loading, success, and recoverable error states.
Add robust validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for scheduling logic and one end-to-end publishing flow.
Create a README covering setup, architecture, permissions, data storage, and backup.
Do not add billing, telemetry, hosted infrastructure, enterprise collaboration, social inbox, listening, analytics dashboards, white-labeling, or unofficial scraping.
Finish by running the tests and listing the exact commands used.

## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.