diff --git a/.agents/skills/company-creator/SKILL.md b/.agents/skills/company-creator/SKILL.md
new file mode 100644
index 00000000000..b2f4432bcdb
--- /dev/null
+++ b/.agents/skills/company-creator/SKILL.md
@@ -0,0 +1,277 @@
+---
+name: company-creator
+description: >
+ Create agent company packages conforming to the Agent Companies specification
+ (agentcompanies/v1). Use when a user wants to create a new agent company from
+ scratch, build a company around an existing git repo or skills collection, or
+ scaffold a team/department of agents. Triggers on: "create a company", "make me
+ a company", "build a company from this repo", "set up an agent company",
+ "create a team of agents", "hire some agents", or when given a repo URL and
+ asked to turn it into a company. Do NOT use for importing an existing company
+ package (use the CLI import command instead) or for modifying a company that
+ is already running in Paperclip.
+---
+
+# Company Creator
+
+Create agent company packages that conform to the Agent Companies specification.
+
+Spec references:
+
+- Normative spec: `docs/companies/companies-spec.md` (read this before generating files)
+- Web spec: https://agentcompanies.io/specification
+- Protocol site: https://agentcompanies.io/
+
+## Two Modes
+
+### Mode 1: Company From Scratch
+
+The user describes what they want. Interview them to flesh out the vision, then generate the package.
+
+### Mode 2: Company From a Repo
+
+The user provides a git repo URL, local path, or tweet. Analyze the repo, then create a company that wraps it.
+
+See [references/from-repo-guide.md](references/from-repo-guide.md) for detailed repo analysis steps.
+
+## Process
+
+### Step 1: Gather Context
+
+Determine which mode applies:
+
+- **From scratch**: What kind of company or team? What domain? What should the agents do?
+- **From repo**: Clone/read the repo. Scan for existing skills, agent configs, README, source structure.
+
+### Step 2: Interview (Use AskUserQuestion)
+
+Do not skip this step. Use AskUserQuestion to align with the user before writing any files.
+
+**For from-scratch companies**, ask about:
+
+- Company purpose and domain (1-2 sentences is fine)
+- What agents they need - propose a hiring plan based on what they described
+- Whether this is a full company (needs a CEO) or a team/department (no CEO required)
+- Any specific skills the agents should have
+- How work flows through the organization (see "Workflow" below)
+- Whether they want projects and starter tasks
+
+**For from-repo companies**, present your analysis and ask:
+
+- Confirm the agents you plan to create and their roles
+- Whether to reference or vendor any discovered skills (default: reference)
+- Any additional agents or skills beyond what the repo provides
+- Company name and any customization
+- Confirm the workflow you inferred from the repo (see "Workflow" below)
+
+**Workflow — how does work move through this company?**
+
+A company is not just a list of agents with skills. It's an organization that takes ideas and turns them into work products. You need to understand the workflow so each agent knows:
+
+- Who gives them work and in what form (a task, a branch, a question, a review request)
+- What they do with it
+- Who they hand off to when they're done, and what that handoff looks like
+- What "done" means for their role
+
+**Not every company is a pipeline.** Infer the right workflow pattern from context:
+
+- **Pipeline** — sequential stages, each agent hands off to the next. Use when the repo/domain has a clear linear process (e.g. plan → build → review → ship → QA, or content ideation → draft → edit → publish).
+- **Hub-and-spoke** — a manager delegates to specialists who report back independently. Use when agents do different kinds of work that don't feed into each other (e.g. a CEO who dispatches to a researcher, a marketer, and an analyst).
+- **Collaborative** — agents work together on the same things as peers. Use for small teams where everyone contributes to the same output (e.g. a design studio, a brainstorming team).
+- **On-demand** — agents are summoned as needed with no fixed flow. Use when agents are more like a toolbox of specialists the user calls directly.
+
+For from-scratch companies, propose a workflow pattern based on what they described and ask if it fits.
+
+For from-repo companies, infer the pattern from the repo's structure. If skills have a clear sequential dependency (like `plan-ceo-review → plan-eng-review → review → ship → qa`), that's a pipeline. If skills are independent capabilities, it's more likely hub-and-spoke or on-demand. State your inference in the interview so the user can confirm or adjust.
+
+**Key interviewing principles:**
+
+- Propose a concrete hiring plan. Don't ask open-ended "what agents do you want?" - suggest specific agents based on context and let the user adjust.
+- Keep it lean. Most users are new to agent companies. A few agents (3-5) is typical for a startup. Don't suggest 10+ agents unless the scope demands it.
+- From-scratch companies should start with a CEO who manages everyone. Teams/departments don't need one.
+- Ask 2-3 focused questions per round, not 10.
+
+### Step 3: Read the Spec
+
+Before generating any files, read the normative spec:
+
+```
+docs/companies/companies-spec.md
+```
+
+Also read the quick reference: [references/companies-spec.md](references/companies-spec.md)
+
+And the example: [references/example-company.md](references/example-company.md)
+
+### Step 4: Generate the Package
+
+Create the directory structure and all files. Follow the spec's conventions exactly.
+
+**Directory structure:**
+
+```
+/
+├── COMPANY.md
+├── agents/
+│ └── /AGENTS.md
+├── teams/
+│ └── /TEAM.md (if teams are needed)
+├── projects/
+│ └── /PROJECT.md (if projects are needed)
+├── tasks/
+│ └── /TASK.md (if tasks are needed)
+├── skills/
+│ └── /SKILL.md (if custom skills are needed)
+└── .paperclip.yaml (Paperclip vendor extension)
+```
+
+**Rules:**
+
+- Slugs must be URL-safe, lowercase, hyphenated
+- COMPANY.md gets `schema: agentcompanies/v1` - other files inherit it
+- Agent instructions go in the AGENTS.md body, not in .paperclip.yaml
+- Skills referenced by shortname in AGENTS.md resolve to `skills//SKILL.md`
+- For external skills, use `sources` with `usage: referenced` (see spec section 12)
+- Do not export secrets, machine-local paths, or database IDs
+- Omit empty/default fields
+- For companies generated from a repo, add a references footer at the bottom of COMPANY.md body:
+ `Generated from [repo-name](repo-url) with the company-creator skill from [Paperclip](https://github.com/paperclipai/paperclip)`
+
+**Reporting structure:**
+
+- Every agent except the CEO should have `reportsTo` set to their manager's slug
+- The CEO has `reportsTo: null`
+- For teams without a CEO, the top-level agent has `reportsTo: null`
+
+**Writing workflow-aware agent instructions:**
+
+Each AGENTS.md body should include not just what the agent does, but how they fit into the organization's workflow. Include:
+
+1. **Where work comes from** — "You receive feature ideas from the user" or "You pick up tasks assigned to you by the CTO"
+2. **What you produce** — "You produce a technical plan with architecture diagrams" or "You produce a reviewed, approved branch ready for shipping"
+3. **Who you hand off to** — "When your plan is locked, hand off to the Staff Engineer for implementation" or "When review passes, hand off to the Release Engineer to ship"
+4. **What triggers you** — "You are activated when a new feature idea needs product-level thinking" or "You are activated when a branch is ready for pre-landing review"
+
+This turns a collection of agents into an organization that actually works together. Without workflow context, agents operate in isolation — they do their job but don't know what happens before or after them.
+
+Add a concise execution contract to every generated working agent:
+
+- Start actionable work in the same heartbeat and do not stop at a plan unless planning was requested.
+- Leave durable progress in comments, documents, or work products with the next action.
+- Use child issues for long or parallel delegated work instead of polling agents, sessions, or processes.
+- Mark blocked work with the unblock owner and action.
+- Respect budget, pause/cancel, approval gates, and company boundaries.
+
+### Step 5: Confirm Output Location
+
+Ask the user where to write the package. Common options:
+
+- A subdirectory in the current repo
+- A new directory the user specifies
+- The current directory (if it's empty or they confirm)
+
+### Step 6: Write README.md and LICENSE
+
+**README.md** — every company package gets a README. It should be a nice, readable introduction that someone browsing GitHub would appreciate. Include:
+
+- Company name and what it does
+- The workflow / how the company operates
+- Org chart as a markdown list or table showing agents, titles, reporting structure, and skills
+- Brief description of each agent's role
+- Citations and references: link to the source repo (if from-repo), link to the Agent Companies spec (https://agentcompanies.io/specification), and link to Paperclip (https://github.com/paperclipai/paperclip)
+- A "Getting Started" section explaining how to import: `paperclipai company import --from `
+
+**LICENSE** — include a LICENSE file. The copyright holder is the user creating the company, not the upstream repo author (they made the skills, the user is making the company). Use the same license type as the source repo (if from-repo) or ask the user (if from-scratch). Default to MIT if unclear.
+
+### Step 7: Write Files and Summarize
+
+Write all files, then give a brief summary:
+
+- Company name and what it does
+- Agent roster with roles and reporting structure
+- Skills (custom + referenced)
+- Projects and tasks if any
+- The output path
+
+## .paperclip.yaml Guidelines
+
+The `.paperclip.yaml` file is the Paperclip vendor extension. It configures adapters and env inputs per agent.
+
+### Adapter Rules
+
+**Do not specify an adapter unless the repo or user context warrants it.** If you don't know what adapter the user wants, omit the adapter block entirely — Paperclip will use its default. Specifying an unknown adapter type causes an import error.
+
+Paperclip's supported adapter types (these are the ONLY valid values):
+- `claude_local` — Claude Code CLI
+- `codex_local` — Codex CLI
+- `opencode_local` — OpenCode CLI
+- `pi_local` — Pi CLI
+- `cursor` — Cursor
+- `gemini_local` — Gemini CLI
+- `openclaw_gateway` — OpenClaw gateway
+
+Only set an adapter when:
+- The repo or its skills clearly target a specific runtime (e.g. gstack is built for Claude Code, so `claude_local` is appropriate)
+- The user explicitly requests a specific adapter
+- The agent's role requires a specific runtime capability
+
+### Env Inputs Rules
+
+**Do not add boilerplate env variables.** Only add env inputs that the agent actually needs based on its skills or role:
+- `GH_TOKEN` for agents that push code, create PRs, or interact with GitHub
+- API keys only when a skill explicitly requires them
+- Never set `ANTHROPIC_API_KEY` as a default empty env variable — the runtime handles this
+
+Example with adapter (only when warranted):
+```yaml
+schema: paperclip/v1
+agents:
+ release-engineer:
+ adapter:
+ type: claude_local
+ config:
+ model: claude-sonnet-4-6
+ inputs:
+ env:
+ GH_TOKEN:
+ kind: secret
+ requirement: optional
+```
+
+Example — only agents with actual overrides appear:
+```yaml
+schema: paperclip/v1
+agents:
+ release-engineer:
+ inputs:
+ env:
+ GH_TOKEN:
+ kind: secret
+ requirement: optional
+```
+
+In this example, only `release-engineer` appears because it needs `GH_TOKEN`. The other agents (ceo, cto, etc.) have no overrides, so they are omitted entirely from `.paperclip.yaml`.
+
+## External Skill References
+
+When referencing skills from a GitHub repo, always use the references pattern:
+
+```yaml
+metadata:
+ sources:
+ - kind: github-file
+ repo: owner/repo
+ path: path/to/SKILL.md
+ commit:
+ attribution: Owner or Org Name
+ license:
+ usage: referenced
+```
+
+Get the commit SHA with:
+
+```bash
+git ls-remote https://github.com/owner/repo HEAD
+```
+
+Do NOT copy external skill content into the package unless the user explicitly asks.
diff --git a/.agents/skills/company-creator/references/companies-spec.md b/.agents/skills/company-creator/references/companies-spec.md
new file mode 100644
index 00000000000..cc8e84e9e03
--- /dev/null
+++ b/.agents/skills/company-creator/references/companies-spec.md
@@ -0,0 +1,144 @@
+# Agent Companies Specification Reference
+
+The normative specification lives at:
+
+- Web: https://agentcompanies.io/specification
+- Local: docs/companies/companies-spec.md
+
+Read the local spec file before generating any package files. The spec defines the canonical format and all frontmatter fields. Below is a quick-reference summary for common authoring tasks.
+
+## Package Kinds
+
+| File | Kind | Purpose |
+| ---------- | ------- | ------------------------------------------------- |
+| COMPANY.md | company | Root entrypoint, org boundary and defaults |
+| TEAM.md | team | Reusable org subtree |
+| AGENTS.md | agent | One role, instructions, and attached skills |
+| PROJECT.md | project | Planned work grouping |
+| TASK.md | task | Portable starter task |
+| SKILL.md | skill | Agent Skills capability package (do not redefine) |
+
+## Directory Layout
+
+```
+company-package/
+├── COMPANY.md
+├── agents/
+│ └── /AGENTS.md
+├── teams/
+│ └── /TEAM.md
+├── projects/
+│ └── /
+│ ├── PROJECT.md
+│ └── tasks/
+│ └── /TASK.md
+├── tasks/
+│ └── /TASK.md
+├── skills/
+│ └── /SKILL.md
+├── assets/
+├── scripts/
+├── references/
+└── .paperclip.yaml (optional vendor extension)
+```
+
+## Common Frontmatter Fields
+
+```yaml
+schema: agentcompanies/v1
+kind: company | team | agent | project | task
+slug: url-safe-stable-identity
+name: Human Readable Name
+description: Short description for discovery
+version: 0.1.0
+license: MIT
+authors:
+ - name: Jane Doe
+tags: []
+metadata: {}
+sources: []
+```
+
+- `schema` usually appears only at package root
+- `kind` is optional when filename makes it obvious
+- `slug` must be URL-safe and stable
+- exporters should omit empty or default-valued fields
+
+## COMPANY.md Required Fields
+
+```yaml
+name: Company Name
+description: What this company does
+slug: company-slug
+schema: agentcompanies/v1
+```
+
+Optional: `version`, `license`, `authors`, `goals`, `includes`, `requirements.secrets`
+
+## AGENTS.md Key Fields
+
+```yaml
+name: Agent Name
+title: Role Title
+reportsTo:
+skills:
+ - skill-shortname
+```
+
+- Body content is the agent's default instructions
+- Skills resolve by shortname: `skills//SKILL.md`
+- Do not export machine-specific paths or secrets
+
+## TEAM.md Key Fields
+
+```yaml
+name: Team Name
+description: What this team does
+slug: team-slug
+manager: ../agent-slug/AGENTS.md
+includes:
+ - ../agent-slug/AGENTS.md
+ - ../../skills/skill-slug/SKILL.md
+```
+
+## PROJECT.md Key Fields
+
+```yaml
+name: Project Name
+description: What this project delivers
+owner: agent-slug
+```
+
+## TASK.md Key Fields
+
+```yaml
+name: Task Name
+assignee: agent-slug
+project: project-slug
+schedule:
+ timezone: America/Chicago
+ startsAt: 2026-03-16T09:00:00-05:00
+ recurrence:
+ frequency: weekly
+ interval: 1
+ weekdays: [monday]
+ time: { hour: 9, minute: 0 }
+```
+
+## Source References (for external skills/content)
+
+```yaml
+sources:
+ - kind: github-file
+ repo: owner/repo
+ path: path/to/SKILL.md
+ commit:
+ sha256:
+ attribution: Owner Name
+ license: MIT
+ usage: referenced
+```
+
+Usage modes: `vendored` (bytes included), `referenced` (pointer only), `mirrored` (cached locally)
+
+Default to `referenced` for third-party content.
diff --git a/.agents/skills/company-creator/references/example-company.md b/.agents/skills/company-creator/references/example-company.md
new file mode 100644
index 00000000000..cbc10d28f15
--- /dev/null
+++ b/.agents/skills/company-creator/references/example-company.md
@@ -0,0 +1,191 @@
+# Example Company Package
+
+A minimal but complete example of an agent company package.
+
+## Directory Structure
+
+```
+lean-dev-shop/
+├── COMPANY.md
+├── agents/
+│ ├── ceo/AGENTS.md
+│ ├── cto/AGENTS.md
+│ └── engineer/AGENTS.md
+├── teams/
+│ └── engineering/TEAM.md
+├── projects/
+│ └── q2-launch/
+│ ├── PROJECT.md
+│ └── tasks/
+│ └── monday-review/TASK.md
+├── tasks/
+│ └── weekly-standup/TASK.md
+├── skills/
+│ └── code-review/SKILL.md
+└── .paperclip.yaml
+```
+
+## COMPANY.md
+
+```markdown
+---
+name: Lean Dev Shop
+description: Small engineering-focused AI company that builds and ships software products
+slug: lean-dev-shop
+schema: agentcompanies/v1
+version: 1.0.0
+license: MIT
+authors:
+ - name: Example Org
+goals:
+ - Build and ship software products
+ - Maintain high code quality
+---
+
+Lean Dev Shop is a small, focused engineering company. The CEO oversees strategy and coordinates work. The CTO leads the engineering team. Engineers build and ship code.
+```
+
+## agents/ceo/AGENTS.md
+
+```markdown
+---
+name: CEO
+title: Chief Executive Officer
+reportsTo: null
+skills:
+ - paperclip
+---
+
+You are the CEO of Lean Dev Shop. You oversee company strategy, coordinate work across the team, and ensure projects ship on time.
+
+Your responsibilities:
+
+- Review and prioritize work across projects
+- Coordinate with the CTO on technical decisions
+- Ensure the company goals are being met
+```
+
+## agents/cto/AGENTS.md
+
+```markdown
+---
+name: CTO
+title: Chief Technology Officer
+reportsTo: ceo
+skills:
+ - code-review
+ - paperclip
+---
+
+You are the CTO of Lean Dev Shop. You lead the engineering team and make technical decisions.
+
+Your responsibilities:
+
+- Set technical direction and architecture
+- Review code and ensure quality standards
+- Mentor engineers and unblock technical challenges
+```
+
+## agents/engineer/AGENTS.md
+
+```markdown
+---
+name: Engineer
+title: Software Engineer
+reportsTo: cto
+skills:
+ - code-review
+ - paperclip
+---
+
+You are a software engineer at Lean Dev Shop. You write code, fix bugs, and ship features.
+
+Your responsibilities:
+
+- Implement features and fix bugs
+- Write tests and documentation
+- Participate in code reviews
+
+Execution contract:
+
+- Start actionable implementation work in the same heartbeat; do not stop at a plan unless planning was requested.
+- Leave durable progress with a clear next action.
+- Use child issues for long or parallel delegated work instead of polling agents, sessions, or processes.
+- Mark blocked work with the unblock owner and action.
+```
+
+## teams/engineering/TEAM.md
+
+```markdown
+---
+name: Engineering
+description: Product and platform engineering team
+slug: engineering
+schema: agentcompanies/v1
+manager: ../../agents/cto/AGENTS.md
+includes:
+ - ../../agents/engineer/AGENTS.md
+ - ../../skills/code-review/SKILL.md
+tags:
+ - engineering
+---
+
+The engineering team builds and maintains all software products.
+```
+
+## projects/q2-launch/PROJECT.md
+
+```markdown
+---
+name: Q2 Launch
+description: Ship the Q2 product launch
+slug: q2-launch
+owner: cto
+---
+
+Deliver all features planned for the Q2 launch, including the new dashboard and API improvements.
+```
+
+## projects/q2-launch/tasks/monday-review/TASK.md
+
+```markdown
+---
+name: Monday Review
+assignee: ceo
+project: q2-launch
+schedule:
+ timezone: America/Chicago
+ startsAt: 2026-03-16T09:00:00-05:00
+ recurrence:
+ frequency: weekly
+ interval: 1
+ weekdays:
+ - monday
+ time:
+ hour: 9
+ minute: 0
+---
+
+Review the status of Q2 Launch project. Check progress on all open tasks, identify blockers, and update priorities for the week.
+```
+
+## skills/code-review/SKILL.md (with external reference)
+
+```markdown
+---
+name: code-review
+description: Thorough code review skill for pull requests and diffs
+metadata:
+ sources:
+ - kind: github-file
+ repo: anthropics/claude-code
+ path: skills/code-review/SKILL.md
+ commit: abc123def456
+ sha256: 3b7e...9a
+ attribution: Anthropic
+ license: MIT
+ usage: referenced
+---
+
+Review code changes for correctness, style, and potential issues.
+```
diff --git a/.agents/skills/company-creator/references/from-repo-guide.md b/.agents/skills/company-creator/references/from-repo-guide.md
new file mode 100644
index 00000000000..b9458693b4b
--- /dev/null
+++ b/.agents/skills/company-creator/references/from-repo-guide.md
@@ -0,0 +1,79 @@
+# Creating a Company From an Existing Repository
+
+When a user provides a git repo (URL, local path, or tweet linking to a repo), analyze it and create a company package that wraps its content.
+
+## Analysis Steps
+
+1. **Clone or read the repo** - Use `git clone` for URLs, read directly for local paths
+2. **Scan for existing agent/skill files** - Look for SKILL.md, AGENTS.md, CLAUDE.md, .claude/ directories, or similar agent configuration
+3. **Understand the repo's purpose** - Read README, package.json, main source files to understand what the project does
+4. **Identify natural agent roles** - Based on the repo's structure and purpose, determine what agents would be useful
+
+## Handling Existing Skills
+
+Many repos already contain skills (SKILL.md files). When you find them:
+
+**Default behavior: use references, not copies.**
+
+Instead of copying skill content into your company package, create a source reference:
+
+```yaml
+metadata:
+ sources:
+ - kind: github-file
+ repo: owner/repo
+ path: path/to/SKILL.md
+ commit:
+ attribution:
+ license:
+ usage: referenced
+```
+
+To get the commit SHA:
+```bash
+git ls-remote https://github.com/owner/repo HEAD
+```
+
+Only vendor (copy) skills when:
+- The user explicitly asks to copy them
+- The skill is very small and tightly coupled to the company
+- The source repo is private or may become unavailable
+
+## Handling Existing Agent Configurations
+
+If the repo has agent configs (CLAUDE.md, .claude/ directories, codex configs, etc.):
+- Use them as inspiration for AGENTS.md instructions
+- Don't copy them verbatim - adapt them to the Agent Companies format
+- Preserve the intent and key instructions
+
+## Repo-Only Skills (No Agents)
+
+When a repo contains only skills and no agents:
+- Create agents that would naturally use those skills
+- The agents should be minimal - just enough to give the skills a runtime context
+- A single agent may use multiple skills from the repo
+- Name agents based on the domain the skills cover
+
+Example: A repo with `code-review`, `testing`, and `deployment` skills might become:
+- A "Lead Engineer" agent with all three skills
+- Or separate "Reviewer", "QA Engineer", and "DevOps" agents if the skills are distinct enough
+
+## Common Repo Patterns
+
+### Developer Tools / CLI repos
+- Create agents for the tool's primary use cases
+- Reference any existing skills
+- Add a project maintainer or lead agent
+
+### Library / Framework repos
+- Create agents for development, testing, documentation
+- Skills from the repo become agent capabilities
+
+### Full Application repos
+- Map to departments: engineering, product, QA
+- Create a lean team structure appropriate to the project size
+
+### Skills Collection repos (e.g. skills.sh repos)
+- Each skill or skill group gets an agent
+- Create a lightweight company or team wrapper
+- Keep the agent count proportional to the skill diversity
diff --git a/skills/create-agent-adapter/SKILL.md b/.agents/skills/create-agent-adapter/SKILL.md
similarity index 98%
rename from skills/create-agent-adapter/SKILL.md
rename to .agents/skills/create-agent-adapter/SKILL.md
index dcd6456ee49..a41318580c8 100644
--- a/skills/create-agent-adapter/SKILL.md
+++ b/.agents/skills/create-agent-adapter/SKILL.md
@@ -548,7 +548,7 @@ Import from `@paperclipai/adapter-utils/server-utils`:
### Prompt Templates
- Support `promptTemplate` for every run
- Use `renderTemplate()` with the standard variable set
-- Default prompt: `"You are agent {{agent.id}} ({{agent.name}}). Continue your Paperclip work."`
+- Default prompt should use `DEFAULT_PAPERCLIP_AGENT_PROMPT_TEMPLATE` from `@paperclipai/adapter-utils/server-utils` so local adapters share Paperclip's execution contract: act in the same heartbeat, avoid planning-only exits unless requested, leave durable progress and a next action, use child issues instead of polling, mark blockers with owner/action, and respect governance boundaries.
### Error Handling
- Differentiate timeout vs process error vs parse failure
diff --git a/.agents/skills/deal-with-security-advisory/SKILL.md b/.agents/skills/deal-with-security-advisory/SKILL.md
new file mode 100644
index 00000000000..0ba122366ec
--- /dev/null
+++ b/.agents/skills/deal-with-security-advisory/SKILL.md
@@ -0,0 +1,230 @@
+---
+name: deal-with-security-advisory
+description: >
+ Handle a GitHub Security Advisory response for Paperclip, including
+ confidential fix development in a temporary private fork, human coordination
+ on advisory-thread comments, CVE request, synchronized advisory publication,
+ and immediate security release steps.
+---
+
+# Security Vulnerability Response Instructions
+
+## ⚠️ CRITICAL: This is a security vulnerability. Everything about this process is confidential until the advisory is published. Do not mention the vulnerability details in any public commit message, PR title, branch name, or comment. Do not push anything to a public branch. Do not discuss specifics in any public channel. Assume anything on the public repo is visible to attackers who will exploit the window between disclosure and user upgrades.
+
+***
+
+## Context
+
+A security vulnerability has been reported via GitHub Security Advisory:
+
+* **Advisory:** {{ghsaId}} (e.g. GHSA-x8hx-rhr2-9rf7)
+* **Reporter:** {{reporterHandle}}
+* **Severity:** {{severity}}
+* **Notes:** {{notes}}
+
+***
+
+## Step 0: Fetch the Advisory Details
+
+Pull the full advisory so you understand the vulnerability before doing anything else:
+
+```
+gh api repos/paperclipai/paperclip/security-advisories/{{ghsaId}}
+
+```
+
+Read the `description`, `severity`, `cvss`, and `vulnerabilities` fields. Understand the attack vector before writing code.
+
+## Step 1: Acknowledge the Report
+
+⚠️ **This step requires a human.** The advisory thread does not have a comment API. Ask the human operator to post a comment on the private advisory thread acknowledging the report. Provide them this template:
+
+> Thanks for the report, @{{reporterHandle}}. We've confirmed the issue and are working on a fix. We're targeting a patch release within {{timeframe}}. We'll keep you updated here.
+
+Give your human this template, but still continue
+
+Below we use `gh` tools - you do have access and credentials outside of your sandbox, so use them.
+
+## Step 2: Create the Temporary Private Fork
+
+This is where all fix development happens. Never push to the public repo.
+
+```
+gh api --method POST \
+ repos/paperclipai/paperclip/security-advisories/{{ghsaId}}/forks
+
+```
+
+This returns a repository object for the private fork. Save the `full_name` and `clone_url`.
+
+Clone it and set up your workspace:
+
+```
+# Clone the private fork somewhere outside ~/paperclip
+git clone ~/security-patch-{{ghsaId}}
+cd ~/security-patch-{{ghsaId}}
+git checkout -b security-fix
+
+```
+
+**Do not edit `~/paperclip`** — the dev server is running off the `~/paperclip` master branch and we don't want to touch it. All work happens in the private fork clone.
+
+**TIPS:**
+
+* Do not commit `pnpm-lock.yaml` — the repo has actions to manage this
+* Do not use descriptive branch names that leak the vulnerability (e.g., no `fix-dns-rebinding-rce`). Use something generic like `security-fix`
+* All work stays in the private fork until publication
+* CI/GitHub Actions will NOT run on the temporary private fork — this is a GitHub limitation by design. You must run tests locally
+
+## Step 3: Develop and Validate the Fix
+
+Write the patch. Same content standards as any PR:
+
+* It must functionally work — **run tests locally** since CI won't run on the private fork
+* Consider the whole codebase, not just the narrow vulnerability path. A patch that fixes one vector but opens another is worse than no patch
+* Ensure backwards compatibility for the database, or be explicit about what breaks
+* Make sure any UI components still look correct if the fix touches them
+* The fix should be minimal and focused — don't bundle unrelated changes into a security patch. Reviewers (and the reporter) should be able to read the diff and understand exactly what changed and why
+
+**Specific to security fixes:**
+
+* Verify the fix actually closes the attack vector described in the advisory. Reproduce the vulnerability first (using the reporter's description), then confirm the patch prevents it
+* Consider adjacent attack vectors — if DNS rebinding is the issue, are there other endpoints or modes with the same class of problem?
+* Do not introduce new dependencies unless absolutely necessary — new deps in a security patch raise eyebrows
+
+Push your fix to the private fork:
+
+```
+git add -A
+git commit -m "Fix security vulnerability"
+git push origin security-fix
+
+```
+
+## Step 4: Coordinate with the Reporter
+
+⚠️ **This step requires a human.** Ask the human operator to post on the advisory thread letting the reporter know the fix is ready and giving them a chance to review. Provide them this template:
+
+> @{{reporterHandle}} — fix is ready in the private fork if you'd like to review before we publish. Planning to release within {{timeframe}}.
+
+Proceed
+
+## Step 5: Request a CVE
+
+This makes vulnerability scanners (npm audit, Snyk, Dependabot) warn users to upgrade. Without it, nobody gets automated notification.
+
+```
+gh api --method POST \
+ repos/paperclipai/paperclip/security-advisories/{{ghsaId}}/cve
+
+```
+
+GitHub is a CVE Numbering Authority and will assign one automatically. The CVE may take a few hours to propagate after the advisory is published.
+
+## Step 6: Publish Everything Simultaneously
+
+This all happens at once — do not stagger these steps. The goal is **zero window** between the vulnerability becoming public knowledge and the fix being available.
+
+### 6a. Verify reporter credit before publishing
+
+```
+gh api repos/paperclipai/paperclip/security-advisories/{{ghsaId}} --jq '.credits'
+
+```
+
+If the reporter is not credited, add them:
+
+```
+gh api --method PATCH \
+ repos/paperclipai/paperclip/security-advisories/{{ghsaId}} \
+ --input - << 'EOF'
+{
+ "credits": [
+ {
+ "login": "{{reporterHandle}}",
+ "type": "reporter"
+ }
+ ]
+}
+EOF
+
+```
+
+### 6b. Update the advisory with the patched version and publish
+
+```
+gh api --method PATCH \
+ repos/paperclipai/paperclip/security-advisories/{{ghsaId}} \
+ --input - << 'EOF'
+{
+ "state": "published",
+ "vulnerabilities": [
+ {
+ "package": {
+ "ecosystem": "npm",
+ "name": "paperclip"
+ },
+ "vulnerable_version_range": "< {{patchedVersion}}",
+ "patched_versions": "{{patchedVersion}}"
+ }
+ ]
+}
+EOF
+
+```
+
+Publishing the advisory simultaneously:
+
+* Makes the GHSA public
+* Merges the temporary private fork into your repo
+* Triggers the CVE assignment (if requested in step 5)
+
+### 6c. Cut a release immediately after merge
+
+```
+cd ~/paperclip
+git pull origin master
+
+gh release create v{{patchedVersion}} \
+ --repo paperclipai/paperclip \
+ --title "v{{patchedVersion}} — Security Release" \
+ --notes "## Security Release
+
+This release fixes a critical security vulnerability.
+
+### What was fixed
+{{briefDescription}} (e.g., Remote code execution via DNS rebinding in \`local_trusted\` mode)
+
+### Advisory
+https://github.com/paperclipai/paperclip/security/advisories/{{ghsaId}}
+
+### Credit
+Thanks to @{{reporterHandle}} for responsibly disclosing this vulnerability.
+
+### Action required
+All users running versions prior to {{patchedVersion}} should upgrade immediately."
+
+```
+
+## Step 7: Post-Publication Verification
+
+```
+# Verify the advisory is published and CVE is assigned
+gh api repos/paperclipai/paperclip/security-advisories/{{ghsaId}} \
+ --jq '{state: .state, cve_id: .cve_id, published_at: .published_at}'
+
+# Verify the release exists
+gh release view v{{patchedVersion}} --repo paperclipai/paperclip
+
+```
+
+If the CVE hasn't been assigned yet, that's normal — it can take a few hours.
+
+⚠️ **Human step:** Ask the human operator to post a final comment on the advisory thread confirming publication and thanking the reporter.
+
+Tell the human operator what you did by posting a comment to this task, including:
+
+* The published advisory URL: `https://github.com/paperclipai/paperclip/security/advisories/{{ghsaId}}`
+* The release URL
+* Whether the CVE has been assigned yet
+* All URLs to any pull requests or branches
diff --git a/.agents/skills/doc-maintenance/SKILL.md b/.agents/skills/doc-maintenance/SKILL.md
new file mode 100644
index 00000000000..a597e90ccbc
--- /dev/null
+++ b/.agents/skills/doc-maintenance/SKILL.md
@@ -0,0 +1,201 @@
+---
+name: doc-maintenance
+description: >
+ Audit top-level documentation (README, SPEC, PRODUCT) against recent git
+ history to find drift — shipped features missing from docs or features
+ listed as upcoming that already landed. Proposes minimal edits, creates
+ a branch, and opens a PR. Use when asked to review docs for accuracy,
+ after major feature merges, or on a periodic schedule.
+---
+
+# Doc Maintenance Skill
+
+Detect documentation drift and fix it via PR — no rewrites, no churn.
+
+## When to Use
+
+- Periodic doc review (e.g. weekly or after releases)
+- After major feature merges
+- When asked "are our docs up to date?"
+- When asked to audit README / SPEC / PRODUCT accuracy
+
+## Target Documents
+
+| Document | Path | What matters |
+|----------|------|-------------|
+| README | `README.md` | Features table, roadmap, quickstart, "what is" accuracy, "works with" table |
+| SPEC | `doc/SPEC.md` | No false "not supported" claims, major model/schema accuracy |
+| PRODUCT | `doc/PRODUCT.md` | Core concepts, feature list, principles accuracy |
+
+Out of scope: DEVELOPING.md, DATABASE.md, CLI.md, doc/plans/, skill files,
+release notes. These are dev-facing or ephemeral — lower risk of user-facing
+confusion.
+
+## Workflow
+
+### Step 1 — Detect what changed
+
+Find the last review cursor:
+
+```bash
+# Read the last-reviewed commit SHA
+CURSOR_FILE=".doc-review-cursor"
+if [ -f "$CURSOR_FILE" ]; then
+ LAST_SHA=$(cat "$CURSOR_FILE" | head -1)
+else
+ # First run: look back 60 days
+ LAST_SHA=$(git log --format="%H" --after="60 days ago" --reverse | head -1)
+fi
+```
+
+Then gather commits since the cursor:
+
+```bash
+git log "$LAST_SHA"..HEAD --oneline --no-merges
+```
+
+### Step 2 — Classify changes
+
+Scan commit messages and changed files. Categorize into:
+
+- **Feature** — new capabilities (keywords: `feat`, `add`, `implement`, `support`)
+- **Breaking** — removed/renamed things (keywords: `remove`, `breaking`, `drop`, `rename`)
+- **Structural** — new directories, config changes, new adapters, new CLI commands
+
+**Ignore:** refactors, test-only changes, CI config, dependency bumps, doc-only
+changes, style/formatting commits. These don't affect doc accuracy.
+
+For borderline cases, check the actual diff — a commit titled "refactor: X"
+that adds a new public API is a feature.
+
+### Step 3 — Build a change summary
+
+Produce a concise list like:
+
+```
+Since last review (, ):
+- FEATURE: Plugin system merged (runtime, SDK, CLI, slots, event bridge)
+- FEATURE: Project archiving added
+- BREAKING: Removed legacy webhook adapter
+- STRUCTURAL: New .agents/skills/ directory convention
+```
+
+If there are no notable changes, skip to Step 7 (update cursor and exit).
+
+### Step 4 — Audit each target doc
+
+For each target document, read it fully and cross-reference against the change
+summary. Check for:
+
+1. **False negatives** — major shipped features not mentioned at all
+2. **False positives** — features listed as "coming soon" / "roadmap" / "planned"
+ / "not supported" / "TBD" that already shipped
+3. **Quickstart accuracy** — install commands, prereqs, and startup instructions
+ still correct (README only)
+4. **Feature table accuracy** — does the features section reflect current
+ capabilities? (README only)
+5. **Works-with accuracy** — are supported adapters/integrations listed correctly?
+
+Use `references/audit-checklist.md` as the structured checklist.
+Use `references/section-map.md` to know where to look for each feature area.
+
+### Step 5 — Create branch and apply minimal edits
+
+```bash
+# Create a branch for the doc updates
+BRANCH="docs/maintenance-$(date +%Y%m%d)"
+git checkout -b "$BRANCH"
+```
+
+Apply **only** the edits needed to fix drift. Rules:
+
+- **Minimal patches only.** Fix inaccuracies, don't rewrite sections.
+- **Preserve voice and style.** Match the existing tone of each document.
+- **No cosmetic changes.** Don't fix typos, reformat tables, or reorganize
+ sections unless they're part of a factual fix.
+- **No new sections.** If a feature needs a whole new section, note it in the
+ PR description as a follow-up — don't add it in a maintenance pass.
+- **Roadmap items:** Move shipped features out of Roadmap. Add a brief mention
+ in the appropriate existing section if there isn't one already. Don't add
+ long descriptions.
+
+### Step 6 — Open a PR
+
+Commit the changes and open a PR:
+
+```bash
+git add README.md doc/SPEC.md doc/PRODUCT.md .doc-review-cursor
+git commit -m "docs: update documentation for accuracy
+
+- [list each fix briefly]
+
+Co-Authored-By: Paperclip "
+
+git push -u origin "$BRANCH"
+
+gh pr create \
+ --title "docs: periodic documentation accuracy update" \
+ --body "$(cat <<'EOF'
+## Summary
+Automated doc maintenance pass. Fixes documentation drift detected since
+last review.
+
+### Changes
+- [list each fix]
+
+### Change summary (since last review)
+- [list notable code changes that triggered doc updates]
+
+## Review notes
+- Only factual accuracy fixes — no style/cosmetic changes
+- Preserves existing voice and structure
+- Larger doc additions (new sections, tutorials) noted as follow-ups
+
+🤖 Generated by doc-maintenance skill
+EOF
+)"
+```
+
+### Step 7 — Update the cursor
+
+After a successful audit (whether or not edits were needed), update the cursor:
+
+```bash
+git rev-parse HEAD > .doc-review-cursor
+```
+
+If edits were made, this is already committed in the PR branch. If no edits
+were needed, commit the cursor update to the current branch.
+
+## Change Classification Rules
+
+| Signal | Category | Doc update needed? |
+|--------|----------|-------------------|
+| `feat:`, `add`, `implement`, `support` in message | Feature | Yes if user-facing |
+| `remove`, `drop`, `breaking`, `!:` in message | Breaking | Yes |
+| New top-level directory or config file | Structural | Maybe |
+| `fix:`, `bugfix` | Fix | No (unless it changes behavior described in docs) |
+| `refactor:`, `chore:`, `ci:`, `test:` | Maintenance | No |
+| `docs:` | Doc change | No (already handled) |
+| Dependency bumps only | Maintenance | No |
+
+## Patch Style Guide
+
+- Fix the fact, not the prose
+- If removing a roadmap item, don't leave a gap — remove the bullet cleanly
+- If adding a feature mention, match the format of surrounding entries
+ (e.g. if features are in a table, add a table row)
+- Keep README changes especially minimal — it shouldn't churn often
+- For SPEC/PRODUCT, prefer updating existing statements over adding new ones
+ (e.g. change "not supported in V1" to "supported via X" rather than adding
+ a new section)
+
+## Output
+
+When the skill completes, report:
+
+- How many commits were scanned
+- How many notable changes were found
+- How many doc edits were made (and to which files)
+- PR link (if edits were made)
+- Any follow-up items that need larger doc work
diff --git a/.agents/skills/doc-maintenance/references/audit-checklist.md b/.agents/skills/doc-maintenance/references/audit-checklist.md
new file mode 100644
index 00000000000..9c13a437d54
--- /dev/null
+++ b/.agents/skills/doc-maintenance/references/audit-checklist.md
@@ -0,0 +1,85 @@
+# Doc Maintenance Audit Checklist
+
+Use this checklist when auditing each target document. For each item, compare
+against the change summary from git history.
+
+## README.md
+
+### Features table
+- [ ] Each feature card reflects a shipped capability
+- [ ] No feature cards for things that don't exist yet
+- [ ] No major shipped features missing from the table
+
+### Roadmap
+- [ ] Nothing listed as "planned" or "coming soon" that already shipped
+- [ ] No removed/cancelled items still listed
+- [ ] Items reflect current priorities (cross-check with recent PRs)
+
+### Quickstart
+- [ ] `npx paperclipai onboard` command is correct
+- [ ] Manual install steps are accurate (clone URL, commands)
+- [ ] Prerequisites (Node version, pnpm version) are current
+- [ ] Server URL and port are correct
+
+### "What is Paperclip" section
+- [ ] High-level description is accurate
+- [ ] Step table (Define goal / Hire team / Approve and run) is correct
+
+### "Works with" table
+- [ ] All supported adapters/runtimes are listed
+- [ ] No removed adapters still listed
+- [ ] Logos and labels match current adapter names
+
+### "Paperclip is right for you if"
+- [ ] Use cases are still accurate
+- [ ] No claims about capabilities that don't exist
+
+### "Why Paperclip is special"
+- [ ] Technical claims are accurate (atomic execution, governance, etc.)
+- [ ] No features listed that were removed or significantly changed
+
+### FAQ
+- [ ] Answers are still correct
+- [ ] No references to removed features or outdated behavior
+
+### Development section
+- [ ] Commands are accurate (`pnpm dev`, `pnpm build`, etc.)
+- [ ] Link to DEVELOPING.md is correct
+
+## doc/SPEC.md
+
+### Company Model
+- [ ] Fields match current schema
+- [ ] Governance model description is accurate
+
+### Agent Model
+- [ ] Adapter types match what's actually supported
+- [ ] Agent configuration description is accurate
+- [ ] No features described as "not supported" or "not V1" that shipped
+
+### Task Model
+- [ ] Task hierarchy description is accurate
+- [ ] Status values match current implementation
+
+### Extensions / Plugins
+- [ ] If plugins are shipped, no "not in V1" or "future" language
+- [ ] Plugin model description matches implementation
+
+### Open Questions
+- [ ] Resolved questions removed or updated
+- [ ] No "TBD" items that have been decided
+
+## doc/PRODUCT.md
+
+### Core Concepts
+- [ ] Company, Employees, Task Management descriptions accurate
+- [ ] Agent Execution modes described correctly
+- [ ] No missing major concepts
+
+### Principles
+- [ ] Principles haven't been contradicted by shipped features
+- [ ] No principles referencing removed capabilities
+
+### User Flow
+- [ ] Dream scenario still reflects actual onboarding
+- [ ] Steps are achievable with current features
diff --git a/.agents/skills/doc-maintenance/references/section-map.md b/.agents/skills/doc-maintenance/references/section-map.md
new file mode 100644
index 00000000000..4ec64f83875
--- /dev/null
+++ b/.agents/skills/doc-maintenance/references/section-map.md
@@ -0,0 +1,22 @@
+# Section Map
+
+Maps feature areas to specific document sections so the skill knows where to
+look when a feature ships or changes.
+
+| Feature Area | README Section | SPEC Section | PRODUCT Section |
+|-------------|---------------|-------------|----------------|
+| Plugins / Extensions | Features table, Roadmap | Extensions, Agent Model | Core Concepts |
+| Adapters (new runtimes) | "Works with" table, FAQ | Agent Model, Agent Configuration | Employees & Agents, Agent Execution |
+| Governance / Approvals | Features table, "Why special" | Board Governance, Board Approval Gates | Principles |
+| Budget / Cost Control | Features table, "Why special" | Budget Delegation | Company (revenue & expenses) |
+| Task Management | Features table | Task Model | Task Management |
+| Org Chart / Hierarchy | Features table | Agent Model (reporting) | Employees & Agents |
+| Multi-Company | Features table, FAQ | Company Model | Company |
+| Heartbeats | Features table, FAQ | Agent Execution | Agent Execution |
+| CLI Commands | Development section | — | — |
+| Onboarding / Quickstart | Quickstart, FAQ | — | User Flow |
+| Skills / Skill Injection | "Why special" | — | — |
+| Company Templates | "Why special", Roadmap (ClipMart) | — | — |
+| Mobile / UI | Features table | — | — |
+| Project Archiving | — | — | — |
+| OpenClaw Integration | "Works with" table, FAQ | Agent Model | Agent Execution |
diff --git a/.agents/skills/pr-report/SKILL.md b/.agents/skills/pr-report/SKILL.md
new file mode 100644
index 00000000000..5064b67c090
--- /dev/null
+++ b/.agents/skills/pr-report/SKILL.md
@@ -0,0 +1,202 @@
+---
+name: pr-report
+description: >
+ Review a pull request or contribution deeply, explain it tutorial-style for a
+ maintainer, and produce a polished report artifact such as HTML or Markdown.
+ Use when asked to analyze a PR, explain a contributor's design decisions,
+ compare it with similar systems, or prepare a merge recommendation.
+---
+
+# PR Report Skill
+
+Produce a maintainer-grade review of a PR, branch, or large contribution.
+
+Default posture:
+
+- understand the change before judging it
+- explain the system as built, not just the diff
+- separate architectural problems from product-scope objections
+- make a concrete recommendation, not a vague impression
+
+## When to Use
+
+Use this skill when the user asks for things like:
+
+- "review this PR deeply"
+- "explain this contribution to me"
+- "make me a report or webpage for this PR"
+- "compare this design to similar systems"
+- "should I merge this?"
+
+## Outputs
+
+Common outputs:
+
+- standalone HTML report in `tmp/reports/...`
+- Markdown report in `report/` or another requested folder
+- short maintainer summary in chat
+
+If the user asks for a webpage, build a polished standalone HTML artifact with
+clear sections and readable visual hierarchy.
+
+Resources bundled with this skill:
+
+- `references/style-guide.md` for visual direction and report presentation rules
+- `assets/html-report-starter.html` for a reusable standalone HTML/CSS starter
+
+## Workflow
+
+### 1. Acquire and frame the target
+
+Work from local code when possible, not just the GitHub PR page.
+
+Gather:
+
+- target branch or worktree
+- diff size and changed subsystems
+- relevant repo docs, specs, and invariants
+- contributor intent if it is documented in PR text or design docs
+
+Start by answering: what is this change *trying* to become?
+
+### 2. Build a mental model of the system
+
+Do not stop at file-by-file notes. Reconstruct the design:
+
+- what new runtime or contract exists
+- which layers changed: db, shared types, server, UI, CLI, docs
+- lifecycle: install, startup, execution, UI, failure, disablement
+- trust boundary: what code runs where, under what authority
+
+For large contributions, include a tutorial-style section that teaches the
+system from first principles.
+
+### 3. Review like a maintainer
+
+Findings come first. Order by severity.
+
+Prioritize:
+
+- behavioral regressions
+- trust or security gaps
+- misleading abstractions
+- lifecycle and operational risks
+- coupling that will be hard to unwind
+- missing tests or unverifiable claims
+
+Always cite concrete file references when possible.
+
+### 4. Distinguish the objection type
+
+Be explicit about whether a concern is:
+
+- product direction
+- architecture
+- implementation quality
+- rollout strategy
+- documentation honesty
+
+Do not hide an architectural objection inside a scope objection.
+
+### 5. Compare to external precedents when needed
+
+If the contribution introduces a framework or platform concept, compare it to
+similar open-source systems.
+
+When comparing:
+
+- prefer official docs or source
+- focus on extension boundaries, context passing, trust model, and UI ownership
+- extract lessons, not just similarities
+
+Good comparison questions:
+
+- Who owns lifecycle?
+- Who owns UI composition?
+- Is context explicit or ambient?
+- Are plugins trusted code or sandboxed code?
+- Are extension points named and typed?
+
+### 6. Make the recommendation actionable
+
+Do not stop at "merge" or "do not merge."
+
+Choose one:
+
+- merge as-is
+- merge after specific redesign
+- salvage specific pieces
+- keep as design research
+
+If rejecting or narrowing, say what should be kept.
+
+Useful recommendation buckets:
+
+- keep the protocol/type model
+- redesign the UI boundary
+- narrow the initial surface area
+- defer third-party execution
+- ship a host-owned extension-point model first
+
+### 7. Build the artifact
+
+Suggested report structure:
+
+1. Executive summary
+2. What the PR actually adds
+3. Tutorial: how the system works
+4. Strengths
+5. Main findings
+6. Comparisons
+7. Recommendation
+
+For HTML reports:
+
+- use intentional typography and color
+- make navigation easy for long reports
+- favor strong section headings and small reference labels
+- avoid generic dashboard styling
+
+Before building from scratch, read `references/style-guide.md`.
+If a fast polished starter is helpful, begin from `assets/html-report-starter.html`
+and replace the placeholder content with the actual report.
+
+### 8. Verify before handoff
+
+Check:
+
+- artifact path exists
+- findings still match the actual code
+- any requested forbidden strings are absent from generated output
+- if tests were not run, say so explicitly
+
+## Review Heuristics
+
+### Plugin and platform work
+
+Watch closely for:
+
+- docs claiming sandboxing while runtime executes trusted host processes
+- module-global state used to smuggle React context
+- hidden dependence on render order
+- plugins reaching into host internals instead of using explicit APIs
+- "capabilities" that are really policy labels on top of fully trusted code
+
+### Good signs
+
+- typed contracts shared across layers
+- explicit extension points
+- host-owned lifecycle
+- honest trust model
+- narrow first rollout with room to grow
+
+## Final Response
+
+In chat, summarize:
+
+- where the report is
+- your overall call
+- the top one or two reasons
+- whether verification or tests were skipped
+
+Keep the chat summary shorter than the report itself.
diff --git a/.agents/skills/pr-report/assets/html-report-starter.html b/.agents/skills/pr-report/assets/html-report-starter.html
new file mode 100644
index 00000000000..be6f0550c8c
--- /dev/null
+++ b/.agents/skills/pr-report/assets/html-report-starter.html
@@ -0,0 +1,426 @@
+
+
+
+
+
+ PR Report Starter
+
+
+
+
+
+
+
+
+
+
+
+
Executive Summary
+
Use the hero for the clearest one-line judgment.
+
+ Replace this with the short explanation of what the contribution does, why it matters,
+ and what the core maintainer question is.
+
+
+ Strength
+ Tradeoff
+ Risk
+
+
+
+
Overall Call
+
Placeholder
+
+
+
Main Concern
+
Placeholder
+
+
+
Best Part
+
Placeholder
+
+
+
Weakest Part
+
Placeholder
+
+
+
+ Use this block for the thesis, a sharp takeaway, or a key cited point.
+
+
+
+
+
Tutorial Section
+
+
+
Concept Card
+
Use cards for mental models, subsystems, or comparison slices.
+
path/to/file.ts:10
+
+
+
Second Card
+
Keep cards fairly dense. This template is about style, not fixed structure.
+
path/to/file.ts:20
+
+
+
+
+
+
Findings
+
+
High
+
Finding Title
+
Use findings for the sharpest judgment calls and risks.
+
path/to/file.ts:30
+
+
+
+
+
Recommendation
+
+
+
Path Forward
+
Use this area for merge guidance, salvage plan, or rollout advice.
+
+
+
What To Keep
+
Call out the parts worth preserving even if the whole proposal should not land.
+
+
+
+
+
+
+
diff --git a/.agents/skills/pr-report/references/style-guide.md b/.agents/skills/pr-report/references/style-guide.md
new file mode 100644
index 00000000000..35158d1adcf
--- /dev/null
+++ b/.agents/skills/pr-report/references/style-guide.md
@@ -0,0 +1,149 @@
+# PR Report Style Guide
+
+Use this guide when the user wants a report artifact, especially a webpage.
+
+## Goal
+
+Make the report feel like an editorial review, not an internal admin dashboard.
+The page should make a long technical argument easy to scan without looking
+generic or overdesigned.
+
+## Visual Direction
+
+Preferred tone:
+
+- editorial
+- warm
+- serious
+- high-contrast
+- handcrafted, not corporate SaaS
+
+Avoid:
+
+- default app-shell layouts
+- purple gradients on white
+- generic card dashboards
+- cramped pages with weak hierarchy
+- novelty fonts that hurt readability
+
+## Typography
+
+Recommended pattern:
+
+- one expressive serif or display face for major headings
+- one sturdy sans-serif for body copy and UI labels
+
+Good combinations:
+
+- Newsreader + IBM Plex Sans
+- Source Serif 4 + Instrument Sans
+- Fraunces + Public Sans
+- Libre Baskerville + Work Sans
+
+Rules:
+
+- headings should feel deliberate and large
+- body copy should stay comfortable for long reading
+- reference labels and badges should use smaller dense sans text
+
+## Layout
+
+Recommended structure:
+
+- a sticky side or top navigation for long reports
+- one strong hero summary at the top
+- panel or paper-like sections for each major topic
+- multi-column card grids for comparisons and strengths
+- single-column body text for findings and recommendations
+
+Use generous spacing. Long-form technical reports need breathing room.
+
+## Color
+
+Prefer muted paper-like backgrounds with one warm accent and one cool counterweight.
+
+Suggested token categories:
+
+- `--bg`
+- `--paper`
+- `--ink`
+- `--muted`
+- `--line`
+- `--accent`
+- `--good`
+- `--warn`
+- `--bad`
+
+The accent should highlight navigation, badges, and important labels. Do not
+let accent colors dominate body text.
+
+## Useful UI Elements
+
+Include small reusable styles for:
+
+- summary metrics
+- badges
+- quotes or callouts
+- finding cards
+- severity labels
+- reference labels
+- comparison cards
+- responsive two-column sections
+
+## Motion
+
+Keep motion restrained.
+
+Good:
+
+- soft fade/slide-in on first load
+- hover response on nav items or cards
+
+Bad:
+
+- constant animation
+- floating blobs
+- decorative motion with no reading benefit
+
+## Content Presentation
+
+Even when the user wants design polish, clarity stays primary.
+
+Good structure for long reports:
+
+1. executive summary
+2. what changed
+3. tutorial explanation
+4. strengths
+5. findings
+6. comparisons
+7. recommendation
+
+The exact headings can change. The important thing is to separate explanation
+from judgment.
+
+## References
+
+Reference labels should be visually quiet but easy to spot.
+
+Good pattern:
+
+- small muted text
+- monospace or compact sans
+- keep them close to the paragraph they support
+
+## Starter Usage
+
+If you need a fast polished base, start from:
+
+- `assets/html-report-starter.html`
+
+Customize:
+
+- fonts
+- color tokens
+- hero copy
+- section ordering
+- card density
+
+Do not preserve the placeholder sections if they do not fit the actual report.
diff --git a/.agents/skills/prcheckloop/SKILL.md b/.agents/skills/prcheckloop/SKILL.md
new file mode 100644
index 00000000000..70d9e19af66
--- /dev/null
+++ b/.agents/skills/prcheckloop/SKILL.md
@@ -0,0 +1,209 @@
+---
+name: prcheckloop
+description: >
+ Iteratively gets a GitHub pull request's checks green. Detects the PR for the
+ current branch or uses a provided PR number, waits for every check on the
+ latest head SHA to appear and finish, investigates failing checks, fixes
+ actionable code or test issues, pushes, and repeats. Escalates with a precise
+ blocker when failures are external, flaky, or not safely fixable. Use when a
+ PR still has unsuccessful checks after review fixes, including after greploop.
+---
+
+# PRCheckloop
+
+Get a GitHub PR to a fully green check state, or exit with a concrete blocker.
+
+## Scope
+
+- GitHub PRs only. If the repo is GitLab, stop and use `check-pr`.
+- Focus on checks for the latest PR head SHA, not old commits.
+- Focus on CI/status checks, not review comments or PR template cleanup.
+- If the user also wants review-comment cleanup, pair this with `check-pr`.
+
+## Inputs
+
+- **PR number** (optional): If not provided, detect the PR for the current branch.
+- **Max iterations**: default `5`.
+
+## Workflow
+
+### 1. Identify the PR
+
+If no PR number is provided, detect it from the current branch:
+
+```bash
+gh pr view --json number,headRefName,headRefOid,url,isDraft
+```
+
+If needed, switch to the PR branch before making changes.
+
+Stop early if:
+
+- `gh` is not authenticated
+- there is no PR for the branch
+- the repo is not hosted on GitHub
+
+### 2. Track the latest head SHA
+
+Always work against the current PR head SHA:
+
+```bash
+PR_JSON=$(gh pr view "$PR_NUMBER" --json number,headRefName,headRefOid,url)
+HEAD_SHA=$(echo "$PR_JSON" | jq -r .headRefOid)
+PR_URL=$(echo "$PR_JSON" | jq -r .url)
+```
+
+Ignore failing checks from older SHAs. After every push, refresh `HEAD_SHA` and
+restart the inspection loop.
+
+### 3. Inventory checks for that SHA
+
+Fetch both GitHub check runs and legacy commit status contexts:
+
+```bash
+gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs?per_page=100"
+gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/status"
+```
+
+For a compact PR-level view, this GraphQL payload is useful:
+
+```bash
+gh api graphql -f query='
+query($owner:String!, $repo:String!, $pr:Int!) {
+ repository(owner:$owner, name:$repo) {
+ pullRequest(number:$pr) {
+ headRefOid
+ url
+ statusCheckRollup {
+ contexts(first:100) {
+ nodes {
+ __typename
+ ... on CheckRun { name status conclusion detailsUrl workflowName }
+ ... on StatusContext { context state targetUrl description }
+ }
+ }
+ }
+ }
+ }
+}' -F owner=OWNER -F repo=REPO -F pr="$PR_NUMBER"
+```
+
+### 4. Wait for checks to actually run
+
+After a new push, checks can take a moment to appear. Poll every 15-30 seconds
+until one of these is true:
+
+- checks have appeared and every item is in a terminal state
+- checks have appeared and at least one failed
+- no checks appear after a reasonable wait, usually 2 minutes
+
+Treat these as terminal success states:
+
+- check runs: `SUCCESS`, `NEUTRAL`, `SKIPPED`
+- status contexts: `SUCCESS`
+
+Treat these as pending:
+
+- check runs: `QUEUED`, `PENDING`, `WAITING`, `REQUESTED`, `IN_PROGRESS`
+- status contexts: `PENDING`
+
+Treat these as failures:
+
+- check runs: `FAILURE`, `TIMED_OUT`, `CANCELLED`, `ACTION_REQUIRED`, `STARTUP_FAILURE`, `STALE`
+- status contexts: `FAILURE`, `ERROR`
+
+If no checks appear for the latest SHA, inspect `.github/workflows/`, workflow
+path filters, and branch protection expectations. If the missing check cannot be
+caused or fixed from the repo, escalate.
+
+### 5. Investigate failing checks
+
+For GitHub Actions failures, inspect runs and failed logs for the current SHA:
+
+```bash
+gh run list --commit "$HEAD_SHA" --json databaseId,workflowName,status,conclusion,url,headSha
+gh run view --json databaseId,name,workflowName,status,conclusion,jobs,url,headSha
+gh run view --log-failed
+```
+
+For each failing check, classify it:
+
+| Failure type | Action |
+|---|---|
+| Code/test regression | Reproduce locally, fix, and verify |
+| Lint/type/build mismatch | Run the matching local command from the workflow and fix it |
+| Flake or transient infra issue | Rerun once if evidence supports flakiness |
+| External service/status app failure | Escalate with the details URL and owner guess |
+| Missing secret/permission/branch protection issue | Escalate immediately |
+
+Only rerun a failed job once without code changes. Do not loop on reruns.
+
+### 6. Fix actionable failures
+
+If the failure is actionable from the checked-out code:
+
+1. Read the workflow or failing command to identify the real gate.
+2. Reproduce locally where reasonable.
+3. Make the smallest correct fix.
+4. Run focused verification first, then broader verification if needed.
+5. Commit in a logical commit.
+6. Push before re-checking the PR.
+
+Do not stop at a local fix. The loop is only complete when the remote PR checks
+for the new head SHA are green.
+
+### 7. Push and repeat
+
+After each fix:
+
+```bash
+git push
+sleep 5
+```
+
+Then refresh the PR metadata, get the new `HEAD_SHA`, and restart from Step 3.
+
+Exit the loop only when:
+
+- all checks for the latest head SHA are green, or
+- a blocker remains after reasonable repair effort, or
+- the max iteration count is reached
+
+### 8. Escalate blockers precisely
+
+If you cannot get the PR green, report:
+
+- PR URL
+- latest head SHA
+- exact failing or missing check names
+- details URLs
+- what you already tried
+- why it is blocked
+- who should likely unblock it
+- the next concrete action
+
+Good blocker examples:
+
+- external status app outage
+- missing GitHub secret or permission
+- required check name mismatch in branch protection
+- persistent flake after one rerun
+- failure needs credentials or infrastructure access you do not have
+
+## Output
+
+When the skill completes, report:
+
+- PR URL and branch
+- final head SHA
+- green/pending/failing check summary
+- fixes made and verification run
+- whether changes were pushed
+- blocker summary if not fully green
+
+## Notes
+
+- This skill is intentionally narrower than `check-pr`: it is a repair loop for
+ PR checks.
+- This skill complements `greploop`: Greptile can be perfect while CI is still
+ red.
diff --git a/.agents/skills/release-changelog-discord-message/SKILL.md b/.agents/skills/release-changelog-discord-message/SKILL.md
new file mode 100644
index 00000000000..df6c85925b6
--- /dev/null
+++ b/.agents/skills/release-changelog-discord-message/SKILL.md
@@ -0,0 +1,406 @@
+---
+name: release-changelog-discord-message
+description: >
+ Write the Discord release announcement for a stable Paperclip release. Companion
+ to `release-changelog` — that skill produces the file at `releases/vYYYY.MDD.P.md`;
+ this one turns that file into a single copy-pasteable Discord post in dotta's
+ voice and attaches it as the `discord_announcement` document on the release
+ issue.
+---
+
+# Release Discord Announcement Skill
+
+Write the Discord release announcement for the **stable** Paperclip release.
+
+This is the companion to `.agents/skills/release-changelog/SKILL.md`. That skill
+generates the file at `releases/vYYYY.MDD.P.md`. This skill turns that file into
+a single copy-pasteable Discord block, in dotta's voice, and posts it as the
+`discord_announcement` document on the release issue.
+
+## What dotta said
+
+> This is for discord — try to follow my format. If I have a section where I
+> think about the future, pull from recent issues we're working on etc.
+
+The Discord announcement is **not** the changelog. The changelog is exhaustive;
+the announcement is opinionated, in-voice, and built around the same handful of
+shipped highlights plus a real "what's next" + "what's on my mind" pulled from
+current Paperclip work — not invented.
+
+## When to use
+
+- After `release-changelog` has produced `releases/vYYYY.MDD.P.md` on the
+ release worktree/PR.
+- When the release issue (the one assigned by the release routine) asks for a
+ Discord announcement, or has a `discord_announcement` document that needs to
+ be refreshed for a new date/version.
+- Never run this in isolation. The version, date, contributor list, and
+ highlight set MUST match the matching changelog file — if the changelog has
+ been updated, refresh this too.
+
+## Output
+
+A single fenced markdown code block, ready to paste into Discord. Attached as
+issue document key `discord_announcement` on the release issue, and pasted
+verbatim into a comment on that issue so the human can copy it out.
+
+```bash
+PUT /api/issues/{releaseIssueId}/documents/discord_announcement
+{
+ "title": "Discord announcement",
+ "format": "markdown",
+ "body": "",
+ "baseRevisionId": ""
+}
+```
+
+If the document already exists, fetch it first and pass the current
+`baseRevisionId`. Never overwrite silently — if the version has changed since
+the document was last written, mention what changed in the issue comment.
+
+## Format (follow this template)
+
+Use Discord emoji shortcodes (`:paperclip:`, `:lock:`, `:brain:` …) — NOT the
+Unicode emoji. Discord renders the shortcodes; the changelog file uses prose.
+
+```
+:paperclip: :paperclip: :paperclip: CLIPPERS!!! v{VERSION} IS OUT :paperclip: :paperclip: :paperclip:
+
+OFFICIAL TWITTER: https://x.com/papercliping - follow it, report any others
+
+## Highlights
+
+:emoji: **Feature Name** - one-sentence description in dotta's voice.
+:emoji: **Feature Name** - …
+:emoji: **Feature Name** - …
+
+... and a long tail of {flavor of the rest}. Read the [full release notes]().
+
+## WHATS NEXT (:motorway: Roadmap)
+
+* **Theme A** - one-line forward-looking blurb
+* **Theme B** - …
+* **Theme C** - …
+
+## What's on my mind
+
+* **Topic** - what's bugging dotta / what's queued / open questions
+* **Topic** - …
+
+## PRESS (optional — only if there is real press)
+
+* **Outlet / Person** - what happened ([link]())
+
+## WHAT I NEED FROM YOU (optional — only if there's a real ask)
+
+FOLLOW THE TWITTER: https://x.com/papercliping - that's the only official one
+TELL ME if you're using Paperclip in your business - I want to meet you
+
+## Community
+
+Thank you to everyone who contributed to this release!
+
+```
+@username1, @username2, @username3
+```
+
+## In Summary
+
+PAPERCLIP IS THE AI ORCHESTRATOR FOR HUMANS TO ACCOMPLISH 100x MORE WORK
+
+Every single person will be managing a team of a dozen, or a hundred, or a
+thousand agents and Paperclip will be the default tool to manage it all.
+
+ITS TIME TO CLIP :paperclip: :paperclip: :paperclip:
+
+FULL RELEASE NOTES
+
+https://github.com/paperclipai/paperclip/blob/master/releases/v{VERSION}.md
+
+||@everyone||
+```
+
+Notes on the template:
+
+- The opening and closing `:paperclip: :paperclip: :paperclip:` bookends are
+ part of the brand — keep them.
+- Sections may be UPPERCASE or Title Case — dotta has used both. Pick a style
+ and stay consistent within a single post.
+- Use `||@everyone||` (Discord spoiler-wrapped) at the very end so it pings
+ exactly once when the spoiler is removed by the poster.
+
+## Language tips
+
+These are extracted from how dotta has written the last several announcements.
+Mimic this register; do not invent a "professional" tone.
+
+- **First person, conversational.** "I want to meet companies using Paperclip",
+ "what's on my mind", "if that's you let me know". Not "Paperclip is excited
+ to announce".
+- **ALL CAPS for excitement and asks**, especially in the opener, the section
+ headers, the "WHAT I NEED FROM YOU" section, and the closing tagline. Do not
+ ALL-CAPS feature descriptions.
+- **One emoji shortcode per highlight bullet**, picked to evoke the feature
+ (`:lock:` for secrets, `:brain:` for planning, `:mag:` for search,
+ `:cloud:` for cloud / sandbox, `:jigsaw:` for plugins, `:rewind:` for
+ history/restore, `:thread:` for threads, etc.).
+- **Highlight bullets are one sentence**, opinionated, told from the user's
+ perspective — "the cloud-secrets prereq is real now", not "added support
+ for…".
+- **Tail line after highlights** wraps the rest in a single sentence and links
+ to the full release notes ("… and a long tail of {flavor}. Read the [full
+ release notes](url).").
+- **"WHATS NEXT" is forward-looking themes**, not a literal sprint list. 3–5
+ bullets is the right size. Pull these from active goals, in-flight projects,
+ and recent issues the team is working on — do not invent themes.
+- **"What's on my mind"** is dotta's personal/strategic thinking — docs gaps,
+ philosophical positioning ("we're the human control plane for ai labor"),
+ invitations ("if you've ever wanted to write about how you use Paperclip,
+ hit me up"). Pull real tensions from recent issues/comments; do not invent.
+- **Press section** is optional. Only include it if there is real press in the
+ release window (a tweet, a podcast, a talk, a star milestone). No press →
+ drop the section entirely.
+- **"WHAT I NEED FROM YOU"** is optional. Use it for a single concrete ask
+ (follow the twitter, intros, beta sign-ups). No real ask → drop it.
+- **Community** is the same contributors list that's in the changelog file,
+ fenced in a triple-backtick block, comma-separated `@username, @username`.
+ Exclude bots and Paperclip founders, same rules as the changelog skill.
+- **The "In Summary" mission line** evolves slowly. Use the most recent
+ variant unless dotta tells you otherwise. Recent variants:
+ - "PAPERCLIP IS THE AI ORCHESTRATOR FOR HUMANS TO ACCOMPLISH 100x MORE WORK"
+ - "PAPERCLIP WILL BE THE DEFAULT AGENT-MANAGEMENT TOOL FOR EVERY COMPANY"
+ - "Paperclip will be _the_ control plane for AI agents in **every** company."
+- **Closing tagline** is always `ITS TIME TO CLIP :paperclip: :paperclip:
+ :paperclip:`. Keep it.
+
+## Workflow
+
+1. Read the matching `releases/vYYYY.MDD.P.md` produced by `release-changelog`.
+ Use the version and contributor list from that file — never re-derive them.
+2. Read the **release issue thread** (the one assigned to you that ran the
+ release routine) — comments + linked issues + recent issues in the company
+ are the source for `WHATS NEXT` and `What's on my mind`. Pull real themes,
+ not invented ones.
+3. Re-read the three verbatim examples below — they're the canonical voice.
+4. Draft the announcement using the template above.
+5. PUT it as the `discord_announcement` document on the release issue (see
+ "Output" above). If updating, send the latest `baseRevisionId`.
+6. Post a comment on the release issue that includes the announcement inside a
+ single fenced markdown code block, so dotta can copy-paste it into Discord
+ without opening the document.
+
+Do not publish to Discord. This skill only prepares the artifact.
+
+## Verbatim previous examples
+
+Three previous Discord announcements from dotta, included **verbatim** as the
+ground-truth examples for voice, structure, and emoji usage. When in doubt,
+match these.
+
+### Example 1 — v2026.403.0
+
+```
+CLIPPERS! v2026.403.0 has dropped!! :paperclip: :paperclip: :paperclip:
+
+## Highlights
+
+:inbox_tray: **Inbox overhaul** - there is a new "mine" tab that has mail-client like keyboard shortcuts. It's my new default view for managing work
+:thumbsup: **Feedback and evals** - you can now vote :thumbsup: / :thumbsdown: on your agent's responses. If you choose to share your traces with me, I'll use it to make Paperclip better. In either case you can export locally for your own org's learning
+:page_with_curl: **Document revisions** - you can now restore old versions of your documents
+:ping_pong: **Telemetry** - this version has anonymized telemetry that helps me better understand the basic uses of Paperclip (adapters and so on) - if you hate that, just it disable with `DO_NOT_TRACK=1` or `PAPERCLIP_TELEMETRY_DISABLED=1` environment variables
+:construction_worker: **Execution Workspaces (experimental)** - Paperclip is not a "code review" tool, but I have been finding worktrees are important for certain projects. Enable it in experimental settings
+:loop: **Routine variables** - sometimes you need to customize a routine and the new variables feature makes that easy
+
+PLUS **tons** of improvements aound adapters, bugfixes, qol
+
+## COMMUNITY
+
+HUGE THANKS to the contributors with commits in this release:
+
+```
+@aronprins, @bittoby, @edimuj, @HenkDz, @kevmok, @mvanhorn, @radiusred, @remdev, @statxc, @vanductai
+```
+
+## WHATS NEXT (ROADMAP)
+
+* **Multi-human users** -- you've been asking for it, we have a draft and will have this shortly
+* **Sandbox execution** - the other half of cloud deployment: run your agents in a sandbox across any provider
+
+PLUS: just dealing with the excellent PRs we have sitting in our inbox.
+
+**What's also on my mind (coming soonish)**
+
+* MAXIMIZER MODE - for when you've got a dream and tokens to burn
+* Artifacts, work products, and deployments
+* CEO Chat
+* Stronger agent defaults
+
+## PRESS
+
+I've been doing my part to spread the word about Paperclip
+
+* We talked to the incredible [Andrew Warner of Mixergy Fame](https://x.com/dotta/status/2039087507514507407)
+* We gave a tutorial with the [inimitable Greg Isenberg](https://x.com/dotta/status/2037279902445994345)
+* We met with the [Seed Club guys](https://x.com/dotta/status/2039020365926576377)
+* We crossed [40k stars (46k now!)](https://x.com/dotta/status/2038638188227387613)
+* ... and a couple others that will be released in a few days
+
+## SUCCESS STORIES
+
+* [Nevo made $76k in march](https://x.com/dotta/status/2039406772859920758) after using Paperclip to automate his marketing
+* [Lewis Jackson](https://x.com/WhatSayLew/status/2039810227394978158) said 34 agents were already operating his trading firm through Paperclip and called it his "holy s***" AI moment.
+* [Neal Kotak](https://x.com/nkotak1/status/2039582439459209638) said Paperclip already runs most of Roominary for him and praised how strong the product is.
+* [Sam Woods](https://x.com/samwoods/status/2039039305960587755) said he knows several people who moved from OpenClaw to Paperclip, often with Hermes in the stack, and that they love it.
+* [Josh Galt](https://x.com/JoshGalt/status/2039386307219095557) called Paperclip the coolest agent tooling he has used and said it is finally something that just works.
+
+## IN SUMMARY
+
+I know there are still some rough edges, but
+
+Paperclip will be *the* control plane for AI agents in **every** company.
+
+and I think we're moving at a pretty good clip :paperclip: :paperclip: :paperclip:
+
+FULL RELEASE NOTES HERE
+
+https://github.com/paperclipai/paperclip/releases/tag/v2026.403.0
+
+||@everyone||
+```
+
+### Example 2 — v2026.416.0
+
+```
+:paperclip: :paperclip: :paperclip: CLIPPERS!!! v2026.416.0 IS OUT :paperclip: :paperclip: :paperclip:
+
+## Highlights
+
+This release has *tons* of quality of life improvements around speed, performance, and workflow. You should notice that comment threads feel faster and your agents stay on task longer
+
+:thread: Issue chat threads now are a conversation more than comments
+:police_officer: Execution policies like **Reviewer** and **Approver** are now first-class in the harness (e.g. enforce that QA *must* review a task)
+:no_smoking: Blocker dependencies - first-class "wake on blocker resolved" which means now you can have "task graphs" that depend on one another and it's enforced by Paperclip
+:woman_feeding_baby: Parent-child tasks - better support for sub-tasks all around, which makes it much easier to organize your work
+
+And then a million fixes around ux, details, keyboard shortcuts, bug fixes, security fixes, etc. Really you should read the [full release notes here](https://github.com/paperclipai/paperclip/releases/tag/v2026.416.0)
+
+## COMMUNITY
+
+INCREDIBLE INCREDIBLE WORK BY folks with commits and reports in this release:
+
+```
+@AllenHyang, @antonio-mello-ai, @aronprins, @chrisschwer, @cleanunicorn, @DanielSousa, @davison, @ergonaworks, @HearthCore, @HenkDz, @KhairulA, @kimnamu, @Lempkey, @marysomething99-prog, @mvanhorn, @officialasishkumar, @plind-dm, @shoaib050326, @sparkeros, @wbelt, @offset, @sagilayani, @mattdonnelly10, @peaktwilight, @YuvalElbar6
+```
+
+## WHATS NEXT (:motorway: Roadmap)
+
+* **Multi-human users** - in the last stages of testing, Paperclip is better with teams
+* **Memory Infrastructure** - your agents will remember everything about yoru business
+* **Sandbox execution** - run your agents anywhere
+
+## What's on my mind
+
+* I want to meet with companies who are using Paperclip in their business - if that's you let me know
+* We need more Paperclip tutorials, defaults, and education - thanks to @aronprins for his work in this area already!
+* We still need to get better at reviewing your PRs and we're improving our process every day
+* "Zero-human company" language has to go - we're the human control plane for ai labor
+* We're adding better support for *knowledge (wikis & files)*, *artifacts*, and *work product* in Paperclip soon.
+
+## PRESS
+
+* **AI Engineer Europe Tutorial** - I gave a tutorial for AIE. If someone is looking for a basics ABC of Paperclip [you can send them this](https://x.com/dotta/status/2044575580264316931)
+* **AI Club Chicago** - JB gave a talk on Paperclip [at AI Tinkerers in Chicago](https://x.com/developwithJB/status/2044281068778316268) !
+
+## IN SUMMARY
+
+PAPERCLIP WILL BE THE DEFAULT AGENT-MANAGEMENT TOOL FOR EVERY COMPANY
+
+If there's anything I can do to help you and your company use Paperclip, hit me up. Until then, enjoy the new release
+
+ITS TIME TO CLIP :paperclip: :paperclip: :paperclip:
+
+FULL RELEASE NOTES
+
+https://github.com/paperclipai/paperclip/releases/tag/v2026.416.0
+
+||@everyone||
+```
+
+### Example 3 — v2026.427.0
+
+```
+:paperclip: :paperclip: :paperclip: CLIPPERS!!! v2026.427.0 IS OUT :paperclip: :paperclip: :paperclip:
+
+THIS IS THE OFFICIAL TWITTER FOLLOW IT: https://x.com/papercliping
+
+## Highlights
+
+:man_feeding_baby: **MULTI USER** - you can now invite multiple users to your instance
+:factory_worker: **HARDER WORKING** - robosut liveness continuations and lifecycle recovery means your instance tries harder before involving you
+:white_check_mark: **SUBISSUE CHECKLISTS** - subissues have better ordering which allows for long-run planning
+:thread: **Rich Thread UX** - now your agents can ask you questions, ask for approvals, suggest tasks and you can approve or refine them right in your task threads
+:cloud: **BETA: Sandbox Providers** - Cloud sandboxing is in beta - the API ships in this release and we'll be adding more providers
+... and *tons* of other improvements and bugfixes.
+
+## Community
+
+Thank you to everyone who contributed to this release!
+
+```
+@akhater, @aronprins, @GodsBoy, @LeonSGP43, @neerazz, @NoronhaH, @rbarinov, @rvanduiven, @SgtPooki, @superbiche
+```
+
+## WHATS NEXT (:motorway: Roadmap)
+
+* **Longer-range planning and execution** - Paperclip will support longer and longer tasks and work until it's done
+* **Secrets Service v2** - an important prereq for Paperclip cloud
+* **Artifacts, memory, and knowledge**
+* **Conference Room** aka CEO/Agent Chat
+
+## What's on my mind
+
+* **Documentation & Blog posts** - I've fallen behind on the docs but aron has done a good job here - we'll be setting up Clips to help maintain these
+* **Paperclip Cloud** - will be a critical unlock for us, but even the shared team story needs developed more - *where should the work be done* and *where are the outputs stored* and *how do we surface them to users*? Each of these questions are a core Paperclip service that needs developed
+* **Paperclip Bench** - In the vein of SWE-Bench I've started an internal benchmark for Paperclip - we have to be able to measure that our changes are improving the system and not regressing
+* **Paperclip Connections Store** - connecting to Github, Slack, Google Docs, and the hundreds of other services we use every day should be easy, secure, and configurable per agent and team
+
+## Press
+
+I met with the [Wisemen about Paperclip](https://x.com/dotta/status/2045146539534827998)
+
+## WHAT I NEED FROM YOU
+
+FOLLOW THIS TWITTER ACCOUNT: https://x.com/papercliping - that's the only official one, report any others
+
+## In Summary
+
+PAPERCLIP IS THE AI ORCHESTRATOR FOR HUMANS TO ACCOMPLISH 100x MORE WORK
+
+Every single person will be managing a team of a dozen, or a hundred, or a thousand agents and Paperclip will be the default tool to manage it all.
+
+ITS TIME TO CLIP :paperclip: :paperclip: :paperclip:
+
+FULL RELEASE NOTES
+
+https://github.com/paperclipai/paperclip/blob/master/releases/v2026.427.0.md
+
+||@everyone||
+```
+
+## Review checklist
+
+Before handing off:
+
+1. Version + date match the matching `releases/vYYYY.MDD.P.md` exactly.
+2. Contributor list matches the changelog (same exclusions: bots, founders).
+3. Highlights are a subset of the changelog Highlights — same shipped features,
+ not invented or pre-alpha work.
+4. `WHATS NEXT` and `What's on my mind` are pulled from real recent issues /
+ active goals — not invented themes.
+5. Section style (UPPERCASE vs Title Case) is internally consistent.
+6. Closing tagline is `ITS TIME TO CLIP :paperclip: :paperclip: :paperclip:`
+ and `||@everyone||` is the very last line.
+7. Document `discord_announcement` is updated on the release issue, and the
+ announcement is also posted in a comment inside a fenced code block.
+
+This skill never posts to Discord. It only prepares the announcement artifact.
diff --git a/.agents/skills/release-changelog/SKILL.md b/.agents/skills/release-changelog/SKILL.md
new file mode 100644
index 00000000000..04de31dc59f
--- /dev/null
+++ b/.agents/skills/release-changelog/SKILL.md
@@ -0,0 +1,196 @@
+---
+name: release-changelog
+description: >
+ Generate the stable Paperclip release changelog at releases/vYYYY.MDD.P.md by
+ reading commits, changesets, and merged PR context since the last stable tag.
+---
+
+# Release Changelog Skill
+
+Generate the user-facing changelog for the **stable** Paperclip release.
+
+## Versioning Model
+
+Paperclip uses **calendar versioning (calver)**:
+
+- Stable releases: `YYYY.MDD.P` (e.g. `2026.318.0`)
+- Canary releases: `YYYY.MDD.P-canary.N` (e.g. `2026.318.1-canary.0`)
+- Git tags: `vYYYY.MDD.P` for stable, `canary/vYYYY.MDD.P-canary.N` for canary
+
+There are no major/minor/patch bumps. The stable version is derived from the
+intended release date (UTC) plus the next same-day stable patch slot.
+
+Output:
+
+- `releases/vYYYY.MDD.P.md`
+
+Important rules:
+
+- even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases/v2026.318.1.md`
+- do not derive versions from semver bump types
+- do not create canary changelog files
+
+## Step 0 — Idempotency Check
+
+Before generating anything, check whether the file already exists:
+
+```bash
+ls releases/vYYYY.MDD.P.md 2>/dev/null
+```
+
+If it exists:
+
+1. read it first
+2. present it to the reviewer
+3. ask whether to keep it, regenerate it, or update specific sections
+4. never overwrite it silently
+
+## Step 1 — Determine the Stable Range
+
+Find the last stable tag:
+
+```bash
+git tag --list 'v*' --sort=-version:refname | head -1
+git log v{last}..HEAD --oneline --no-merges
+```
+
+The stable version comes from one of:
+
+- an explicit maintainer request
+- `./scripts/release.sh stable --date YYYY-MM-DD --print-version`
+- the release plan already agreed in `doc/RELEASING.md`
+
+Do not derive the changelog version from a canary tag or prerelease suffix.
+Do not derive major/minor/patch bumps from API intent — calver uses the date and same-day stable slot.
+
+## Step 2 — Gather the Raw Inputs
+
+Collect release data from:
+
+1. git commits since the last stable tag
+2. `.changeset/*.md` files
+3. merged PRs via `gh` when available
+
+Useful commands:
+
+```bash
+git log v{last}..HEAD --oneline --no-merges
+git log v{last}..HEAD --format="%H %s" --no-merges
+ls .changeset/*.md | grep -v README.md
+gh pr list --state merged --search "merged:>={last-tag-date}" --json number,title,body,labels
+```
+
+## Step 3 — Detect Breaking Changes
+
+Look for:
+
+- destructive migrations
+- removed or changed API fields/endpoints
+- renamed or removed config keys
+- `BREAKING:` or `BREAKING CHANGE:` commit signals
+
+Key commands:
+
+```bash
+git diff --name-only v{last}..HEAD -- packages/db/src/migrations/
+git diff v{last}..HEAD -- packages/db/src/schema/
+git diff v{last}..HEAD -- server/src/routes/ server/src/api/
+git log v{last}..HEAD --format="%s" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true
+```
+
+If breaking changes are detected, flag them prominently — they must appear in the
+Breaking Changes section with an upgrade path.
+
+## Step 4 — Categorize for Users
+
+Use these stable changelog sections:
+
+- `Breaking Changes`
+- `Highlights`
+- `Improvements`
+- `Fixes`
+- `Upgrade Guide` when needed
+
+Exclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.
+
+Guidelines:
+
+- group related commits into one user-facing entry
+- write from the user perspective
+- keep highlights short and concrete
+- spell out upgrade actions for breaking changes
+
+### Inline PR and contributor attribution
+
+When a bullet item clearly maps to a merged pull request, add inline attribution at the
+end of the entry in this format:
+
+```
+- **Feature name** — Description. ([#123](https://github.com/paperclipai/paperclip/pull/123), @contributor1, @contributor2)
+```
+
+Rules:
+
+- Only add a PR link when you can confidently trace the bullet to a specific merged PR.
+ Use merge commit messages (`Merge pull request #N from user/branch`) to map PRs.
+- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.
+- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.
+- If you cannot determine the PR number or contributor with confidence, omit the attribution
+ parenthetical — do not guess.
+- Core maintainer commits that don't have an external PR can omit the parenthetical.
+
+## Step 5 — Write the File
+
+Template:
+
+```markdown
+# vYYYY.MDD.P
+
+> Released: YYYY-MM-DD
+
+## Breaking Changes
+
+## Highlights
+
+## Improvements
+
+## Fixes
+
+## Upgrade Guide
+
+## Contributors
+
+Thank you to everyone who contributed to this release!
+
+@username1, @username2, @username3
+```
+
+Omit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.
+
+The `Contributors` section should always be included. List every person who authored
+commits in the release range, @-mentioning them by their **GitHub username** (not their
+real name or email). To find GitHub usernames:
+
+1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username/branch`) gives the GitHub username.
+2. For noreply emails like `user@users.noreply.github.com`, the username is the part before `@`.
+3. For contributors whose username is ambiguous, check `gh api users/{guess}` or the PR page.
+
+**Never expose contributor email addresses.** Use `@username` only.
+
+Exclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list.
+Exclude Paperclip founders from the list (e.g. `cryppadotta`, `forgottendev`, `devinfoley`, `sockmonster`, `scotttong`)
+
+List contributors in alphabetical order by GitHub username (case-insensitive).
+
+If there are no contributors left after exclusions, then just skip this section and don't mention it.
+
+## Step 6 — Review Before Release
+
+Before handing it off:
+
+1. confirm the heading is the stable version only
+2. confirm there is no `-canary` language in the title or filename
+3. confirm any breaking changes have an upgrade path
+4. present the draft for human sign-off
+
+This skill never publishes anything. It only prepares the stable changelog artifact.
diff --git a/.agents/skills/release/SKILL.md b/.agents/skills/release/SKILL.md
new file mode 100644
index 00000000000..8f8e7ca25de
--- /dev/null
+++ b/.agents/skills/release/SKILL.md
@@ -0,0 +1,247 @@
+---
+name: release
+description: >
+ Coordinate a full Paperclip release across engineering verification, npm,
+ GitHub, smoke testing, and announcement follow-up. Use when leadership asks
+ to ship a release, not merely to discuss versioning.
+---
+
+# Release Coordination Skill
+
+Run the full Paperclip maintainer release workflow, not just an npm publish.
+
+This skill coordinates:
+
+- stable changelog drafting via `release-changelog`
+- canary verification and publish status from `master`
+- Docker smoke testing via `scripts/docker-onboard-smoke.sh`
+- manual stable promotion from a chosen source ref
+- GitHub Release creation
+- website / announcement follow-up tasks
+
+## Trigger
+
+Use this skill when leadership asks for:
+
+- "do a release"
+- "ship the release"
+- "promote this canary to stable"
+- "cut the stable release"
+
+## Preconditions
+
+Before proceeding, verify all of the following:
+
+1. `.agents/skills/release-changelog/SKILL.md` exists and is usable.
+2. The repo working tree is clean, including untracked files.
+3. There is at least one canary or candidate commit since the last stable tag.
+4. The candidate SHA has passed the verification gate or is about to.
+5. If manifests changed, the CI-owned `pnpm-lock.yaml` refresh is already merged on `master`.
+6. npm publish rights are available through GitHub trusted publishing, or through local npm auth for emergency/manual use.
+7. If running through Paperclip, you have issue context for status updates and follow-up task creation.
+
+If any precondition fails, stop and report the blocker.
+
+## Inputs
+
+Collect these inputs up front:
+
+- whether the target is a canary check or a stable promotion
+- the candidate `source_ref` for stable
+- whether the stable run is dry-run or live
+- release issue / company context for website and announcement follow-up
+
+## Step 0 — Release Model
+
+Paperclip now uses a commit-driven release model:
+
+1. every push to `master` publishes a canary automatically
+2. canaries use `YYYY.MDD.P-canary.N`
+3. stable releases use `YYYY.MDD.P`
+4. the middle slot is `MDD`, where `M` is the UTC month and `DD` is the zero-padded UTC day
+5. the stable patch slot increments when more than one stable ships on the same UTC date
+6. stable releases are manually promoted from a chosen tested commit or canary source commit
+7. only stable releases get `releases/vYYYY.MDD.P.md`, git tag `vYYYY.MDD.P`, and a GitHub Release
+
+Critical consequences:
+
+- do not use release branches as the default path
+- do not derive major/minor/patch bumps
+- do not create canary changelog files
+- do not create canary GitHub Releases
+
+## Step 1 — Choose the Candidate
+
+For canary validation:
+
+- inspect the latest successful canary run on `master`
+- record the canary version and source SHA
+
+For stable promotion:
+
+1. choose the tested source ref
+2. confirm it is the exact SHA you want to promote
+3. resolve the target stable version with `./scripts/release.sh stable --date YYYY-MM-DD --print-version`
+
+Useful commands:
+
+```bash
+git tag --list 'v*' --sort=-version:refname | head -1
+git log --oneline --no-merges
+npm view paperclipai@canary version
+```
+
+## Step 2 — Draft the Stable Changelog
+
+Stable changelog files live at:
+
+- `releases/vYYYY.MDD.P.md`
+
+Invoke `release-changelog` and generate or update the stable notes only.
+
+Rules:
+
+- review the draft with a human before publish
+- preserve manual edits if the file already exists
+- keep the filename stable-only
+- do not create a canary changelog file
+
+## Step 3 — Verify the Candidate SHA
+
+Run the standard gate:
+
+```bash
+pnpm -r typecheck
+pnpm test:run
+pnpm build
+```
+
+If the GitHub release workflow will run the publish, it can rerun this gate. Still report local status if you checked it.
+
+For PRs that touch release logic, the repo also runs a canary release dry-run in CI. That is a release-specific guard, not a substitute for the standard gate.
+
+## Step 4 — Validate the Canary
+
+The normal canary path is automatic from `master` via:
+
+- `.github/workflows/release.yml`
+
+Confirm:
+
+1. verification passed
+2. npm canary publish succeeded
+3. git tag `canary/vYYYY.MDD.P-canary.N` exists
+
+Useful checks:
+
+```bash
+npm view paperclipai@canary version
+git tag --list 'canary/v*' --sort=-version:refname | head -5
+```
+
+## Step 5 — Smoke Test the Canary
+
+Run:
+
+```bash
+PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh
+```
+
+Useful isolated variant:
+
+```bash
+HOST_PORT=3232 DATA_DIR=./data/release-smoke-canary PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh
+```
+
+Confirm:
+
+1. install succeeds
+2. onboarding completes without crashes
+3. the server boots
+4. the UI loads
+5. basic company creation and dashboard load work
+
+If smoke testing fails:
+
+- stop the stable release
+- fix the issue on `master`
+- wait for the next automatic canary
+- rerun smoke testing
+
+## Step 6 — Preview or Publish Stable
+
+The normal stable path is manual `workflow_dispatch` on:
+
+- `.github/workflows/release.yml`
+
+Inputs:
+
+- `source_ref`
+- `stable_date`
+- `dry_run`
+
+Before live stable:
+
+1. resolve the target stable version with `./scripts/release.sh stable --date YYYY-MM-DD --print-version`
+2. ensure `releases/vYYYY.MDD.P.md` exists on the source ref
+3. run the stable workflow in dry-run mode first when practical
+4. then run the real stable publish
+
+The stable workflow:
+
+- re-verifies the exact source ref
+- computes the next stable patch slot for the chosen UTC date
+- publishes `YYYY.MDD.P` under dist-tag `latest`
+- creates git tag `vYYYY.MDD.P`
+- creates or updates the GitHub Release from `releases/vYYYY.MDD.P.md`
+
+Local emergency/manual commands:
+
+```bash
+./scripts/release.sh stable --dry-run
+./scripts/release.sh stable
+git push public-gh refs/tags/vYYYY.MDD.P
+./scripts/create-github-release.sh YYYY.MDD.P
+```
+
+## Step 7 — Finish the Other Surfaces
+
+Create or verify follow-up work for:
+
+- website changelog publishing
+- launch post / social announcement
+- release summary in Paperclip issue context
+
+These should reference the stable release, not the canary.
+
+## Failure Handling
+
+If the canary is bad:
+
+- publish another canary, do not ship stable
+
+If stable npm publish succeeds but tag push or GitHub release creation fails:
+
+- fix the git/GitHub issue immediately from the same release result
+- do not republish the same version
+
+If `latest` is bad after stable publish:
+
+```bash
+./scripts/rollback-latest.sh
+```
+
+Then fix forward with a new stable release.
+
+## Output
+
+When the skill completes, provide:
+
+- candidate SHA and tested canary version, if relevant
+- stable version, if promoted
+- verification status
+- npm status
+- smoke-test status
+- git tag / GitHub Release status
+- website / announcement follow-up status
+- rollback recommendation if anything is still partially complete
diff --git a/.changeset/README.md b/.changeset/README.md
deleted file mode 100644
index 654c6d4750d..00000000000
--- a/.changeset/README.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Changesets
-
-Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
-with multi-package repos, or single-package repos to help you version and publish your code. You can
-find the full documentation for it [in our repository](https://github.com/changesets/changesets).
-
-We have a quick list of common questions to get you started engaging with this project in
-[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).
diff --git a/.changeset/config.json b/.changeset/config.json
deleted file mode 100644
index 5373961171e..00000000000
--- a/.changeset/config.json
+++ /dev/null
@@ -1,11 +0,0 @@
-{
- "$schema": "https://unpkg.com/@changesets/config@3.1.3/schema.json",
- "changelog": "@changesets/cli/changelog",
- "commit": false,
- "fixed": [["@paperclipai/*", "paperclipai"]],
- "linked": [],
- "access": "public",
- "baseBranch": "master",
- "updateInternalDependencies": "patch",
- "ignore": ["@paperclipai/ui"]
-}
diff --git a/.claude/skills/company-creator b/.claude/skills/company-creator
new file mode 120000
index 00000000000..8e2823ffa0e
--- /dev/null
+++ b/.claude/skills/company-creator
@@ -0,0 +1 @@
+../../.agents/skills/company-creator
\ No newline at end of file
diff --git a/.env b/.env
new file mode 100644
index 00000000000..1ca81248b36
--- /dev/null
+++ b/.env
@@ -0,0 +1,12 @@
+# DATABASE_URL=postgres://paperclip:paperclip@localhost:5432/paperclip
+PORT=3100
+SERVE_UI=true
+BETTER_AUTH_SECRET=paperclip-dev-secret
+
+# Paperclip API (for agent import)
+PAPERCLIP_API_URL=http://localhost:3100
+PAPERCLIP_API_KEY=pc_test_b6be659b410cc4f1818f0a7e8eba1518
+
+# Notifications
+# TELEGRAM_BOT_TOKEN=xxxxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+# TELEGRAM_CHAT_ID=xxxxxxxxxx
diff --git a/.env.example b/.env.example
index b1cab5a5f21..84e20d96058 100644
--- a/.env.example
+++ b/.env.example
@@ -1,3 +1,7 @@
DATABASE_URL=postgres://paperclip:paperclip@localhost:5432/paperclip
PORT=3100
SERVE_UI=false
+BETTER_AUTH_SECRET=paperclip-dev-secret
+
+# Discord webhook for daily merge digest (scripts/discord-daily-digest.sh)
+# DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/...
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
new file mode 100644
index 00000000000..0b8981e1516
--- /dev/null
+++ b/.github/CODEOWNERS
@@ -0,0 +1,17 @@
+# Replace @cryppadotta if a different maintainer or team should own release infrastructure.
+
+.github/** @cryppadotta @devinfoley
+scripts/release*.sh @cryppadotta @devinfoley
+scripts/release-*.mjs @cryppadotta @devinfoley
+scripts/create-github-release.sh @cryppadotta @devinfoley
+scripts/rollback-latest.sh @cryppadotta @devinfoley
+doc/RELEASING.md @cryppadotta @devinfoley
+doc/PUBLISHING.md @cryppadotta @devinfoley
+doc/RELEASE-AUTOMATION-SETUP.md @cryppadotta @devinfoley
+
+# Package files — dependency changes require review
+# package.json matches recursively at all depths (covers root + all workspaces)
+package.json @cryppadotta @devinfoley
+pnpm-lock.yaml @cryppadotta @devinfoley
+pnpm-workspace.yaml @cryppadotta @devinfoley
+.npmrc @cryppadotta @devinfoley
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 00000000000..c12c05eb70f
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,68 @@
+## Thinking Path
+
+
+
+> - Paperclip orchestrates AI agents for zero-human companies
+> - [Which subsystem or capability is involved]
+> - [What problem or gap exists]
+> - [Why it needs to be addressed]
+> - This pull request ...
+> - The benefit is ...
+
+## What Changed
+
+
+
+-
+
+## Verification
+
+
+
+-
+
+## Risks
+
+
+
+-
+
+> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`.
+
+## Model Used
+
+
+
+-
+
+## Checklist
+
+- [ ] I have included a thinking path that traces from project context to this change
+- [ ] I have specified the model used (with version and capability details)
+- [ ] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
+- [ ] I have run tests locally and they pass
+- [ ] I have added or updated tests where applicable
+- [ ] If this change affects the UI, I have included before/after screenshots
+- [ ] I have updated relevant documentation to reflect my changes
+- [ ] I have considered and documented any risks above
+- [ ] I will address all Greptile and reviewer comments before requesting merge
diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml
new file mode 100644
index 00000000000..08ff2462f0d
--- /dev/null
+++ b/.github/workflows/docker.yml
@@ -0,0 +1,55 @@
+name: Docker
+
+on:
+ push:
+ branches:
+ - "master"
+ tags:
+ - "v*"
+
+permissions:
+ contents: read
+ packages: write
+
+jobs:
+ build-and-push:
+ runs-on: ubuntu-latest
+ timeout-minutes: 60
+ concurrency:
+ group: docker-${{ github.ref }}
+ cancel-in-progress: true
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v4
+
+ - name: Login to GitHub Container Registry
+ uses: docker/login-action@v3
+ with:
+ registry: ghcr.io
+ username: ${{ github.repository_owner }}
+ password: ${{ secrets.GITHUB_TOKEN }}
+
+ - name: Set up Docker Buildx
+ uses: docker/setup-buildx-action@v3
+
+ - name: Docker meta
+ id: meta
+ uses: docker/metadata-action@v5
+ with:
+ images: ghcr.io/${{ github.repository }}
+ tags: |
+ type=raw,value=latest,enable={{is_default_branch}}
+ type=semver,pattern={{version}}
+ type=semver,pattern={{major}}.{{minor}}
+ type=sha
+
+ - name: Build and push
+ uses: docker/build-push-action@v6
+ with:
+ context: .
+ platforms: linux/amd64,linux/arm64
+ push: true
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+ tags: ${{ steps.meta.outputs.tags }}
+ labels: ${{ steps.meta.outputs.labels }}
diff --git a/.github/workflows/e2e.yml b/.github/workflows/e2e.yml
new file mode 100644
index 00000000000..8d15462704a
--- /dev/null
+++ b/.github/workflows/e2e.yml
@@ -0,0 +1,44 @@
+name: E2E Tests
+
+on:
+ workflow_dispatch:
+ inputs:
+ skip_llm:
+ description: "Skip LLM-dependent assertions (default: true)"
+ type: boolean
+ default: true
+
+jobs:
+ e2e:
+ runs-on: ubuntu-latest
+ timeout-minutes: 30
+ env:
+ PAPERCLIP_E2E_SKIP_LLM: ${{ inputs.skip_llm && 'true' || 'false' }}
+ ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+ steps:
+ - uses: actions/checkout@v4
+
+ - uses: pnpm/action-setup@v4
+ with:
+ version: 9
+
+ - uses: actions/setup-node@v4
+ with:
+ node-version: 20
+ cache: pnpm
+
+ - run: pnpm install --frozen-lockfile
+ - run: pnpm build
+ - run: npx playwright install --with-deps chromium
+
+ - name: Run e2e tests
+ run: pnpm run test:e2e
+
+ - uses: actions/upload-artifact@v4
+ if: always()
+ with:
+ name: playwright-report
+ path: |
+ tests/e2e/playwright-report/
+ tests/e2e/test-results/
+ retention-days: 14
diff --git a/.github/workflows/pr.yml b/.github/workflows/pr.yml
new file mode 100644
index 00000000000..fa0817968d9
--- /dev/null
+++ b/.github/workflows/pr.yml
@@ -0,0 +1,307 @@
+name: PR
+
+on:
+ pull_request:
+ branches:
+ - master
+
+concurrency:
+ group: pr-${{ github.event.pull_request.number }}
+ cancel-in-progress: true
+
+jobs:
+ policy:
+ runs-on: ubuntu-latest
+ timeout-minutes: 5
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+
+ - name: Block manual lockfile edits
+ if: github.head_ref != 'chore/refresh-lockfile'
+ run: |
+ # Diff the PR branch against its merge base so recent base-branch commits
+ # do not masquerade as changes made by the PR itself.
+ changed="$(git diff --name-only "${{ github.event.pull_request.base.sha }}...${{ github.event.pull_request.head.sha }}")"
+ if printf '%s\n' "$changed" | grep -qx 'pnpm-lock.yaml'; then
+ echo "Do not commit pnpm-lock.yaml in pull requests. CI owns lockfile updates."
+ exit 1
+ fi
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+ run_install: false
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+
+ - name: Validate Dockerfile deps stage
+ run: node ./scripts/check-docker-deps-stage.mjs
+
+ - name: Validate release package manifest
+ run: node ./scripts/release-package-map.mjs check
+
+ - name: Verify release package bootstrap for changed manifests
+ run: |
+ mapfile -t changed_paths < <(git diff --name-only "${{ github.event.pull_request.base.sha }}...${{ github.event.pull_request.head.sha }}")
+ PAPERCLIP_RELEASE_BOOTSTRAP_BASE_SHA="${{ github.event.pull_request.base.sha }}" \
+ node ./scripts/check-release-package-bootstrap.mjs "${changed_paths[@]}"
+
+ - name: Validate dependency resolution when manifests change
+ run: |
+ changed="$(git diff --name-only "${{ github.event.pull_request.base.sha }}...${{ github.event.pull_request.head.sha }}")"
+ manifest_pattern='(^|/)package\.json$|^pnpm-workspace\.yaml$|^\.npmrc$|^pnpmfile\.(cjs|js|mjs)$'
+ if printf '%s\n' "$changed" | grep -Eq "$manifest_pattern"; then
+ pnpm install --lockfile-only --ignore-scripts --no-frozen-lockfile
+ fi
+
+ typecheck_release_registry:
+ name: Typecheck + Release Registry
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 20
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Typecheck workspaces whose build scripts skip TypeScript
+ run: pnpm run typecheck:build-gaps
+
+ - name: Verify release registry test coverage
+ run: pnpm run test:release-registry
+
+ general_tests:
+ name: General tests (${{ matrix.group_label }})
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 20
+ strategy:
+ fail-fast: false
+ matrix:
+ include:
+ - group: general-server
+ group_label: server
+ - group: general-workspaces-a
+ group_label: workspaces-a
+ - group: general-workspaces-b
+ group_label: workspaces-b
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Run grouped general test suites
+ run: pnpm test:run:general -- --group '${{ matrix.group }}'
+
+ verify:
+ # Preserve the legacy required-check name while the underlying work runs in parallel.
+ name: verify
+ if: ${{ always() }}
+ needs: [typecheck_release_registry, general_tests, build]
+ runs-on: ubuntu-latest
+ timeout-minutes: 5
+
+ steps:
+ - name: Fail if any split verify lane failed
+ env:
+ TYPECHECK_RELEASE_REGISTRY_RESULT: ${{ needs.typecheck_release_registry.result }}
+ GENERAL_TESTS_RESULT: ${{ needs.general_tests.result }}
+ BUILD_RESULT: ${{ needs.build.result }}
+ run: |
+ test "$TYPECHECK_RELEASE_REGISTRY_RESULT" = "success"
+ test "$GENERAL_TESTS_RESULT" = "success"
+ test "$BUILD_RESULT" = "success"
+
+ build:
+ name: Build
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 20
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Build
+ run: pnpm build
+
+ verify_serialized_server:
+ name: Verify serialized server suites (${{ matrix.shard_label }})
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 20
+ strategy:
+ fail-fast: false
+ matrix:
+ include:
+ - shard_index: 0
+ shard_count: 4
+ shard_label: 1/4
+ - shard_index: 1
+ shard_count: 4
+ shard_label: 2/4
+ - shard_index: 2
+ shard_count: 4
+ shard_label: 3/4
+ - shard_index: 3
+ shard_count: 4
+ shard_label: 4/4
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Run serialized server test shard
+ run: pnpm test:run:serialized -- --shard-index ${{ matrix.shard_index }} --shard-count ${{ matrix.shard_count }}
+
+ canary_dry_run:
+ name: Canary Dry Run
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 20
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ # `release.sh` always executes its Step 2/7 workspace build, even when
+ # `--skip-verify` bypasses the initial verification gate.
+ - name: Release canary dry run via release.sh internal build
+ run: |
+ git checkout -B master HEAD
+ git checkout -- pnpm-lock.yaml
+ ./scripts/release.sh canary --skip-verify --dry-run
+
+ e2e:
+ needs: [policy]
+ runs-on: ubuntu-latest
+ timeout-minutes: 30
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Install Playwright
+ run: npx playwright install --with-deps chromium
+
+ - name: Generate Paperclip config
+ run: |
+ mkdir -p ~/.paperclip/instances/default
+ cat > ~/.paperclip/instances/default/config.json << 'CONF'
+ {
+ "$meta": { "version": 1, "updatedAt": "2026-01-01T00:00:00.000Z", "source": "onboard" },
+ "database": { "mode": "embedded-postgres" },
+ "logging": { "mode": "file" },
+ "server": { "deploymentMode": "local_trusted", "host": "127.0.0.1", "port": 3100 },
+ "auth": { "baseUrlMode": "auto" },
+ "storage": { "provider": "local_disk" },
+ "secrets": { "provider": "local_encrypted", "strictMode": false }
+ }
+ CONF
+
+ - name: Run e2e tests
+ env:
+ PAPERCLIP_E2E_SKIP_LLM: "true"
+ run: pnpm run test:e2e
+
+ - name: Upload Playwright report
+ uses: actions/upload-artifact@v4
+ if: always()
+ with:
+ name: playwright-report
+ path: |
+ tests/e2e/playwright-report/
+ tests/e2e/test-results/
+ retention-days: 14
diff --git a/.github/workflows/refresh-lockfile.yml b/.github/workflows/refresh-lockfile.yml
new file mode 100644
index 00000000000..a52d6f002f8
--- /dev/null
+++ b/.github/workflows/refresh-lockfile.yml
@@ -0,0 +1,96 @@
+name: Refresh Lockfile
+
+on:
+ push:
+ branches:
+ - master
+ workflow_dispatch:
+
+concurrency:
+ group: refresh-lockfile-master
+ cancel-in-progress: false
+
+jobs:
+ refresh:
+ runs-on: ubuntu-latest
+ timeout-minutes: 10
+ permissions:
+ contents: write
+ pull-requests: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+ run_install: false
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 20
+ cache: pnpm
+
+ - name: Refresh pnpm lockfile
+ run: pnpm install --lockfile-only --ignore-scripts --no-frozen-lockfile
+
+ - name: Fail on unexpected file changes
+ run: |
+ changed="$(git status --porcelain)"
+ if [ -z "$changed" ]; then
+ echo "Lockfile is already up to date."
+ exit 0
+ fi
+ if printf '%s\n' "$changed" | grep -Fvq ' pnpm-lock.yaml'; then
+ echo "Unexpected files changed during lockfile refresh:"
+ echo "$changed"
+ exit 1
+ fi
+
+ - name: Create or update pull request
+ id: upsert-pr
+ env:
+ GH_TOKEN: ${{ github.token }}
+ REPO_OWNER: ${{ github.repository_owner }}
+ run: |
+ if git diff --quiet -- pnpm-lock.yaml; then
+ echo "Lockfile unchanged, nothing to do."
+ echo "pr_url=" >> "$GITHUB_OUTPUT"
+ exit 0
+ fi
+
+ BRANCH="chore/refresh-lockfile"
+ git config user.name "lockfile-bot"
+ git config user.email "lockfile-bot@users.noreply.github.com"
+
+ git checkout -B "$BRANCH"
+ git add pnpm-lock.yaml
+ git commit -m "chore(lockfile): refresh pnpm-lock.yaml"
+ git push --force origin "$BRANCH"
+
+ # Only reuse an open PR from this repository owner, not a fork with the same branch name.
+ pr_url="$(
+ gh pr list --state open --head "$BRANCH" --json url,headRepositoryOwner \
+ --jq ".[] | select(.headRepositoryOwner.login == \"$REPO_OWNER\") | .url" |
+ head -n 1
+ )"
+ if [ -z "$pr_url" ]; then
+ pr_url="$(gh pr create \
+ --head "$BRANCH" \
+ --title "chore(lockfile): refresh pnpm-lock.yaml" \
+ --body "Auto-generated lockfile refresh after dependencies changed on master. This PR only updates pnpm-lock.yaml.")"
+ echo "Created new PR: $pr_url"
+ else
+ echo "PR already exists: $pr_url"
+ fi
+ echo "pr_url=$pr_url" >> "$GITHUB_OUTPUT"
+
+ - name: Enable auto-merge for lockfile PR
+ if: steps.upsert-pr.outputs.pr_url != ''
+ env:
+ GH_TOKEN: ${{ github.token }}
+ run: |
+ gh pr merge --auto --squash --delete-branch "${{ steps.upsert-pr.outputs.pr_url }}"
diff --git a/.github/workflows/release-smoke.yml b/.github/workflows/release-smoke.yml
new file mode 100644
index 00000000000..823a578cf1e
--- /dev/null
+++ b/.github/workflows/release-smoke.yml
@@ -0,0 +1,118 @@
+name: Release Smoke
+
+on:
+ workflow_dispatch:
+ inputs:
+ paperclip_version:
+ description: Published Paperclip dist-tag to test
+ required: true
+ default: canary
+ type: choice
+ options:
+ - canary
+ - latest
+ host_port:
+ description: Host port for the Docker smoke container
+ required: false
+ default: "3232"
+ type: string
+ artifact_name:
+ description: Artifact name for uploaded diagnostics
+ required: false
+ default: release-smoke
+ type: string
+ workflow_call:
+ inputs:
+ paperclip_version:
+ required: true
+ type: string
+ host_port:
+ required: false
+ default: "3232"
+ type: string
+ artifact_name:
+ required: false
+ default: release-smoke
+ type: string
+
+jobs:
+ smoke:
+ runs-on: ubuntu-latest
+ timeout-minutes: 45
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Install Playwright browser
+ run: npx playwright install --with-deps chromium
+
+ - name: Launch Docker smoke harness
+ run: |
+ metadata_file="$RUNNER_TEMP/release-smoke.env"
+ HOST_PORT="${{ inputs.host_port }}" \
+ DATA_DIR="$RUNNER_TEMP/release-smoke-data" \
+ PAPERCLIPAI_VERSION="${{ inputs.paperclip_version }}" \
+ SMOKE_DETACH=true \
+ SMOKE_METADATA_FILE="$metadata_file" \
+ ./scripts/docker-onboard-smoke.sh
+ set -a
+ source "$metadata_file"
+ set +a
+ {
+ echo "SMOKE_BASE_URL=$SMOKE_BASE_URL"
+ echo "SMOKE_ADMIN_EMAIL=$SMOKE_ADMIN_EMAIL"
+ echo "SMOKE_ADMIN_PASSWORD=$SMOKE_ADMIN_PASSWORD"
+ echo "SMOKE_CONTAINER_NAME=$SMOKE_CONTAINER_NAME"
+ echo "SMOKE_DATA_DIR=$SMOKE_DATA_DIR"
+ echo "SMOKE_IMAGE_NAME=$SMOKE_IMAGE_NAME"
+ echo "SMOKE_PAPERCLIPAI_VERSION=$SMOKE_PAPERCLIPAI_VERSION"
+ echo "SMOKE_METADATA_FILE=$metadata_file"
+ } >> "$GITHUB_ENV"
+
+ - name: Run release smoke Playwright suite
+ env:
+ PAPERCLIP_RELEASE_SMOKE_BASE_URL: ${{ env.SMOKE_BASE_URL }}
+ PAPERCLIP_RELEASE_SMOKE_EMAIL: ${{ env.SMOKE_ADMIN_EMAIL }}
+ PAPERCLIP_RELEASE_SMOKE_PASSWORD: ${{ env.SMOKE_ADMIN_PASSWORD }}
+ run: pnpm run test:release-smoke
+
+ - name: Capture Docker logs
+ if: always()
+ run: |
+ if [[ -n "${SMOKE_CONTAINER_NAME:-}" ]]; then
+ docker logs "$SMOKE_CONTAINER_NAME" >"$RUNNER_TEMP/docker-onboard-smoke.log" 2>&1 || true
+ fi
+
+ - name: Upload diagnostics
+ if: always()
+ uses: actions/upload-artifact@v4
+ with:
+ name: ${{ inputs.artifact_name }}
+ path: |
+ ${{ runner.temp }}/docker-onboard-smoke.log
+ ${{ env.SMOKE_METADATA_FILE }}
+ tests/release-smoke/playwright-report/
+ tests/release-smoke/test-results/
+ retention-days: 14
+
+ - name: Stop Docker smoke container
+ if: always()
+ run: |
+ if [[ -n "${SMOKE_CONTAINER_NAME:-}" ]]; then
+ docker rm -f "$SMOKE_CONTAINER_NAME" >/dev/null 2>&1 || true
+ fi
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
new file mode 100644
index 00000000000..c16bad2323d
--- /dev/null
+++ b/.github/workflows/release.yml
@@ -0,0 +1,273 @@
+name: Release
+
+on:
+ push:
+ branches:
+ - master
+ workflow_dispatch:
+ inputs:
+ source_ref:
+ description: Commit SHA, branch, or tag to publish as stable
+ required: true
+ type: string
+ default: master
+ stable_date:
+ description: Enter a UTC date in YYYY-MM-DD format, for example 2026-03-18. Do not enter a version string. The workflow will resolve that date to a stable version such as 2026.318.0, then 2026.318.1 for the next same-day stable.
+ required: false
+ type: string
+ dry_run:
+ description: Preview the stable release without publishing
+ required: true
+ type: boolean
+ default: false
+
+concurrency:
+ group: release-${{ github.event_name }}-${{ github.ref }}
+ cancel-in-progress: false
+
+jobs:
+ verify_canary:
+ if: github.event_name == 'push'
+ runs-on: ubuntu-latest
+ timeout-minutes: 30
+ permissions:
+ contents: read
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Validate release package manifest
+ run: node ./scripts/release-package-map.mjs check
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Typecheck
+ run: pnpm -r typecheck
+
+ - name: Run tests
+ run: pnpm test:run
+
+ - name: Build
+ run: pnpm build
+
+ publish_canary:
+ if: github.event_name == 'push'
+ needs: verify_canary
+ runs-on: ubuntu-latest
+ timeout-minutes: 45
+ environment: npm-canary
+ permissions:
+ contents: write
+ id-token: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Validate release package manifest
+ run: node ./scripts/release-package-map.mjs check
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Restore tracked install-time changes
+ run: git checkout -- pnpm-lock.yaml
+
+ - name: Configure git author
+ run: |
+ git config user.name "github-actions[bot]"
+ git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+
+ - name: Publish canary
+ env:
+ GITHUB_ACTIONS: "true"
+ run: ./scripts/release.sh canary --skip-verify
+
+ - name: Push canary tag
+ run: |
+ tag="$(git tag --points-at HEAD | grep '^canary/v' | head -1)"
+ if [ -z "$tag" ]; then
+ echo "Error: no canary tag points at HEAD after release." >&2
+ exit 1
+ fi
+ git push origin "refs/tags/${tag}"
+
+ verify_stable:
+ if: github.event_name == 'workflow_dispatch'
+ runs-on: ubuntu-latest
+ timeout-minutes: 30
+ permissions:
+ contents: read
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ ref: ${{ inputs.source_ref }}
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Validate release package manifest
+ run: node ./scripts/release-package-map.mjs check
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Typecheck
+ run: pnpm -r typecheck
+
+ - name: Run tests
+ run: pnpm test:run
+
+ - name: Build
+ run: pnpm build
+
+ preview_stable:
+ if: github.event_name == 'workflow_dispatch' && inputs.dry_run
+ needs: verify_stable
+ runs-on: ubuntu-latest
+ timeout-minutes: 45
+ permissions:
+ contents: read
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ ref: ${{ inputs.source_ref }}
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Validate release package manifest
+ run: node ./scripts/release-package-map.mjs check
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Dry-run stable release
+ env:
+ GITHUB_ACTIONS: "true"
+ run: |
+ args=(stable --skip-verify --dry-run)
+ if [ -n "${{ inputs.stable_date }}" ]; then
+ args+=(--date "${{ inputs.stable_date }}")
+ fi
+ ./scripts/release.sh "${args[@]}"
+
+ publish_stable:
+ if: github.event_name == 'workflow_dispatch' && !inputs.dry_run
+ needs: verify_stable
+ runs-on: ubuntu-latest
+ timeout-minutes: 45
+ environment: npm-stable
+ permissions:
+ contents: write
+ id-token: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ ref: ${{ inputs.source_ref }}
+
+ - name: Setup pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.15.4
+
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: 24
+ cache: pnpm
+
+ - name: Install dependencies
+ run: pnpm install --no-frozen-lockfile
+
+ - name: Restore tracked install-time changes
+ run: git checkout -- pnpm-lock.yaml
+
+ - name: Configure git author
+ run: |
+ git config user.name "github-actions[bot]"
+ git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+
+ - name: Publish stable
+ env:
+ GITHUB_ACTIONS: "true"
+ run: |
+ args=(stable --skip-verify)
+ if [ -n "${{ inputs.stable_date }}" ]; then
+ args+=(--date "${{ inputs.stable_date }}")
+ fi
+ ./scripts/release.sh "${args[@]}"
+
+ - name: Push stable tag
+ run: |
+ tag="$(git tag --points-at HEAD | grep '^v' | head -1)"
+ if [ -z "$tag" ]; then
+ echo "Error: no stable tag points at HEAD after release." >&2
+ exit 1
+ fi
+ git push origin "refs/tags/${tag}"
+
+ - name: Create GitHub Release
+ env:
+ GH_TOKEN: ${{ github.token }}
+ PUBLISH_REMOTE: origin
+ run: |
+ version="$(git tag --points-at HEAD | grep '^v' | head -1 | sed 's/^v//')"
+ if [ -z "$version" ]; then
+ echo "Error: no v* tag points at HEAD after stable release." >&2
+ exit 1
+ fi
+ ./scripts/create-github-release.sh "$version"
diff --git a/.gitignore b/.gitignore
index 9d9f5e35522..2d8d5454c87 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,9 @@
+node_modules
node_modules/
+**/node_modules
+**/node_modules/
dist/
+ui/storybook-static/
.env
*.tsbuildinfo
drizzle/meta/
@@ -31,9 +35,26 @@ server/src/**/*.js.map
server/src/**/*.d.ts
server/src/**/*.d.ts.map
tmp/
+feedback-export-*
+diagnostics/
# Editor / tool temp files
*.tmp
.vscode/
.claude/settings.local.json
-.paperclip-local/
\ No newline at end of file
+.paperclip-local/
+/.idea/
+/.agents/
+
+# Doc maintenance cursor
+.doc-review-cursor
+
+# Playwright
+tests/e2e/test-results/
+tests/e2e/playwright-report/
+tests/release-smoke/test-results/
+tests/release-smoke/playwright-report/
+.superset/
+.superpowers/
+.claude/worktrees/
+.herenow
diff --git a/.mailmap b/.mailmap
index 4a1dd6697a2..31780e745b2 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1 +1,3 @@
-Dotta Forgotten
+Dotta <34892728+cryppadotta@users.noreply.github.com>
+Dotta
+Dotta
diff --git a/AGENTS.md b/AGENTS.md
index e4b5b514546..3555bfcdaf0 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -26,6 +26,9 @@ Before making changes, read in this order:
- `ui/`: React + Vite board UI
- `packages/db/`: Drizzle schema, migrations, DB clients
- `packages/shared/`: shared types, constants, validators, API path constants
+- `packages/adapters/`: agent adapter implementations (Claude, Codex, Cursor, etc.)
+- `packages/adapter-utils/`: shared adapter utilities
+- `packages/plugins/`: plugin system packages
- `doc/`: operational and product docs
## 4. Dev Setup (Auto DB)
@@ -78,6 +81,9 @@ If you change schema/API behavior, update all impacted layers:
4. Do not replace strategic docs wholesale unless asked.
Prefer additive updates. Keep `doc/SPEC.md` and `doc/SPEC-implementation.md` aligned.
+5. Keep repo plan docs dated and centralized.
+When you are creating a plan file in the repository itself, new plan documents belong in `doc/plans/` and should use `YYYY-MM-DD-slug.md` filenames. This does not replace Paperclip issue planning: if a Paperclip issue asks for a plan, update the issue `plan` document per the `paperclip` skill instead of creating a repo markdown file.
+
## 6. Database Change Workflow
When changing data model:
@@ -102,7 +108,24 @@ Notes:
## 7. Verification Before Hand-off
-Run this full check before claiming done:
+Default local/agent test path:
+
+```sh
+pnpm test
+```
+
+This is the cheap default and only runs the Vitest suite. Browser suites stay opt-in:
+
+```sh
+pnpm test:e2e
+pnpm test:release-smoke
+```
+
+Run the browser suites only when your change touches them or when you are explicitly verifying CI/release flows.
+
+For normal issue work, run the smallest relevant verification first. Do not default to repo-wide typecheck/build/test on every heartbeat when a narrower check is enough to prove the change.
+
+Run this full check before claiming repo work done in a PR-ready hand-off, or when the change scope is broad enough that targeted checks are not sufficient:
```sh
pnpm -r typecheck
@@ -132,7 +155,18 @@ When adding endpoints:
- Use company selection context for company-scoped pages
- Surface failures clearly; do not silently ignore API errors
-## 10. Definition of Done
+## 10. Pull Request Requirements
+
+When creating a pull request (via `gh pr create` or any other method), you **must** read and fill in every section of [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md). Do not craft ad-hoc PR bodies — use the template as the structure for your PR description. Required sections:
+
+- **Thinking Path** — trace reasoning from project context to this change (see `CONTRIBUTING.md` for examples)
+- **What Changed** — bullet list of concrete changes
+- **Verification** — how a reviewer can confirm it works
+- **Risks** — what could go wrong
+- **Model Used** — the AI model that produced or assisted with the change (provider, exact model ID, context window, capabilities). Write "None — human-authored" if no AI was used.
+- **Checklist** — all items checked
+
+## 11. Definition of Done
A change is done when all are true:
@@ -140,3 +174,45 @@ A change is done when all are true:
2. Typecheck, tests, and build pass
3. Contracts are synced across db/shared/server/ui
4. Docs updated when behavior or commands change
+5. PR description follows the [PR template](.github/PULL_REQUEST_TEMPLATE.md) with all sections filled in (including Model Used)
+
+## 11. Fork-Specific: HenkDz/paperclip
+
+This is a fork of `paperclipai/paperclip` with QoL patches and an **external-only** Hermes adapter story on branch `feat/externalize-hermes-adapter` ([tree](https://github.com/HenkDz/paperclip/tree/feat/externalize-hermes-adapter)).
+
+### Branch Strategy
+
+- `feat/externalize-hermes-adapter` → core has **no** `hermes-paperclip-adapter` dependency and **no** built-in `hermes_local` registration. Install Hermes via the Adapter Plugin manager (`@henkey/hermes-paperclip-adapter` or a `file:` path).
+- Older fork branches may still document built-in Hermes; treat this file as authoritative for the externalize branch.
+
+### Hermes (plugin only)
+
+- Register through **Board → Adapter manager** (same as Droid). Type remains `hermes_local` once the package is loaded.
+- UI uses generic **config-schema** + **ui-parser.js** from the package — no Hermes imports in `server/` or `ui/` source.
+- Optional: `file:` entry in `~/.paperclip/adapter-plugins.json` for local dev of the adapter repo.
+
+### Local Dev
+
+- Fork runs on port 3101+ (auto-detects if 3100 is taken by upstream instance)
+- `npx vite build` hangs on NTFS — use `node node_modules/vite/bin/vite.js build` instead
+- Server startup from NTFS takes 30-60s — don't assume failure immediately
+- Kill ALL paperclip processes before starting: `pkill -f "paperclip"; pkill -f "tsx.*index.ts"`
+- Vite cache survives `rm -rf dist` — delete both: `rm -rf ui/dist ui/node_modules/.vite`
+
+### Fork QoL Patches (not in upstream)
+
+These are local modifications in the fork's UI. If re-copying source, these must be re-applied:
+
+1. **stderr_group** — amber accordion for MCP init noise in `RunTranscriptView.tsx`
+2. **tool_group** — accordion for consecutive non-terminal tools (write, read, search, browser)
+3. **Dashboard excerpt** — `LatestRunCard` strips markdown, shows first 3 lines/280 chars
+
+### Plugin System
+
+PR #2218 (`feat/external-adapter-phase1`) adds external adapter support. See root `AGENTS.md` for full details.
+
+- Adapters can be loaded as external plugins via `~/.paperclip/adapter-plugins.json`
+- The plugin-loader should have ZERO hardcoded adapter imports — pure dynamic loading
+- `createServerAdapter()` must include ALL optional fields (especially `detectModel`)
+- Built-in UI adapters can shadow external plugin parsers — remove built-in when fully externalizing
+- Reference external adapters: Hermes (`@henkey/hermes-paperclip-adapter` or `file:`) and Droid (npm)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000000..a69aa86d144
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,109 @@
+# Contributing Guide
+
+Thanks for wanting to contribute!
+
+We really appreciate both small fixes and thoughtful larger changes.
+
+## Two Paths to Get Your Pull Request Accepted
+
+### Path 1: Small, Focused Changes (Fastest way to get merged)
+
+- Pick **one** clear thing to fix/improve
+- Touch the **smallest possible number of files**
+- Make sure the change is very targeted and easy to review
+- All tests pass and CI is green
+- Greptile score is 5/5 with all comments addressed
+- Use the [PR template](.github/PULL_REQUEST_TEMPLATE.md)
+
+These almost always get merged quickly when they're clean.
+
+### Path 2: Bigger or Impactful Changes
+
+- **First** talk about it in Discord → #dev channel
+ → Describe what you're trying to solve
+ → Share rough ideas / approach
+- Once there's rough agreement, build it
+- In your PR include:
+ - Before / After screenshots (or short video if UI/behavior change)
+ - Clear description of what & why
+ - Proof it works (manual testing notes)
+ - All tests passing and CI green
+ - Greptile score 5/5 with all comments addressed
+ - [PR template](.github/PULL_REQUEST_TEMPLATE.md) fully filled out
+
+PRs that follow this path are **much** more likely to be accepted, even when they're large.
+
+## PR Requirements (all PRs)
+
+### Use the PR Template
+
+Every pull request **must** follow the PR template at [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md). If you create a PR via the GitHub API or other tooling that bypasses the template, copy its contents into your PR description manually. The template includes required sections: Thinking Path, What Changed, Verification, Risks, Model Used, and a Checklist.
+
+### Model Used (Required)
+
+Every PR must include a **Model Used** section specifying which AI model produced or assisted with the change. Include the provider, exact model ID/version, context window size, and any relevant capability details (e.g., reasoning mode, tool use). If no AI was used, write "None — human-authored". This applies to all contributors — human and AI alike.
+
+### Tests Must Pass
+
+All tests must pass before a PR can be merged. Run them locally first and verify CI is green after pushing.
+
+### Greptile Review
+
+We use [Greptile](https://greptile.com) for automated code review. Your PR must achieve a **5/5 Greptile score** with **all Greptile comments addressed** before it can be merged. If Greptile leaves comments, fix or respond to each one and request a re-review.
+
+## Feature Contributions
+
+We actively manage the core Paperclip feature roadmap.
+
+Uncoordinated feature PRs against the core product may be closed, even when the implementation is thoughtful and high quality. That is about roadmap ownership, product coherence, and long-term maintenance commitment, not a judgment about the effort.
+
+If you want to contribute a feature:
+
+- Check [ROADMAP.md](ROADMAP.md) first
+- Start the discussion in Discord -> `#dev` before writing code
+- If the idea fits as an extension, prefer building it with the [plugin system](doc/plugins/PLUGIN_SPEC.md)
+- If you want to show a possible direction, reference implementations are welcome as feedback, but they generally will not be merged directly into core
+
+Bugs, docs improvements, and small targeted improvements are still the easiest path to getting merged, and we really do appreciate them.
+
+## General Rules (both paths)
+
+- Write clear commit messages
+- Keep PR title + description meaningful
+- One PR = one logical change (unless it's a small related group)
+- Run tests locally first
+- Be kind in discussions 😄
+
+## Writing a Good PR message
+
+Your PR description must follow the [PR template](.github/PULL_REQUEST_TEMPLATE.md). All sections are required. The "thinking path" at the top explains from the top of the project down to what you fixed. E.g.:
+
+### Thinking Path Example 1:
+
+> - Paperclip orchestrates ai-agents for zero-human companies
+> - There are many types of adapters for each LLM model provider
+> - But LLM's have a context limit and not all agents can automatically compact their context
+> - So we need to have an adapter-specific configuration for which adapters can and cannot automatically compact their context
+> - This pull request adds per-adapter configuration of compaction, either auto or paperclip managed
+> - That way we can get optimal performance from any adapter/provider in Paperclip
+
+### Thinking Path Example 2:
+
+> - Paperclip orchestrates ai-agents for zero-human companies
+> - But humans want to watch the agents and oversee their work
+> - Human users also operate in teams and so they need their own logins, profiles, views etc.
+> - So we have a multi-user system for humans
+> - But humans want to be able to update their own profile picture and avatar
+> - But the avatar upload form wasn't saving the avatar to the file storage system
+> - So this PR fixes the avatar upload form to use the file storage service
+> - The benefit is we don't have a one-off file storage for just one aspect of the system, which would cause confusion and extra configuration
+
+Then have the rest of your normal PR message after the Thinking Path.
+
+This should include details about what you did, why you did it, why it matters & the benefits, how we can verify it works, and any risks.
+
+Please include screenshots if possible if you have a visible change. (use something like the [agent-browser skill](https://github.com/vercel-labs/agent-browser/blob/main/skills/agent-browser/SKILL.md) or similar to take screenshots). Ideally, you include before and after screenshots.
+
+Questions? Just ask in #dev — we're happy to help.
+
+Happy hacking!
diff --git a/Dockerfile b/Dockerfile
index 2339d2ff880..03f26942b40 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,8 +1,16 @@
-FROM node:20-bookworm-slim AS base
+# syntax=docker/dockerfile:1.20
+FROM node:lts-trixie-slim AS base
+ARG USER_UID=1000
+ARG USER_GID=1000
RUN apt-get update \
- && apt-get install -y --no-install-recommends ca-certificates curl git \
- && rm -rf /var/lib/apt/lists/*
-RUN corepack enable
+ && apt-get install -y --no-install-recommends ca-certificates gosu curl gh git wget ripgrep python3 \
+ && rm -rf /var/lib/apt/lists/* \
+ && corepack enable
+
+# Modify the existing node user/group to have the specified UID/GID to match host user
+RUN usermod -u $USER_UID --non-unique node \
+ && groupmod -g $USER_GID --non-unique node \
+ && usermod -g $USER_GID -d /paperclip node
FROM base AS deps
WORKDIR /app
@@ -13,21 +21,50 @@ COPY ui/package.json ui/
COPY packages/shared/package.json packages/shared/
COPY packages/db/package.json packages/db/
COPY packages/adapter-utils/package.json packages/adapter-utils/
+COPY packages/mcp-server/package.json packages/mcp-server/
+COPY packages/adapters/acpx-local/package.json packages/adapters/acpx-local/
COPY packages/adapters/claude-local/package.json packages/adapters/claude-local/
COPY packages/adapters/codex-local/package.json packages/adapters/codex-local/
+COPY packages/adapters/cursor-cloud/package.json packages/adapters/cursor-cloud/
+COPY packages/adapters/cursor-local/package.json packages/adapters/cursor-local/
+COPY packages/adapters/gemini-local/package.json packages/adapters/gemini-local/
+COPY packages/adapters/grok-local/package.json packages/adapters/grok-local/
+COPY packages/adapters/openclaw-gateway/package.json packages/adapters/openclaw-gateway/
+COPY packages/adapters/opencode-local/package.json packages/adapters/opencode-local/
+COPY packages/adapters/pi-local/package.json packages/adapters/pi-local/
+COPY packages/plugins/sdk/package.json packages/plugins/sdk/
+COPY --parents packages/plugins/sandbox-providers/./*/package.json packages/plugins/sandbox-providers/
+COPY packages/plugins/paperclip-plugin-fake-sandbox/package.json packages/plugins/paperclip-plugin-fake-sandbox/
+COPY packages/plugins/plugin-llm-wiki/package.json packages/plugins/plugin-llm-wiki/
+COPY packages/plugins/plugin-workspace-diff/package.json packages/plugins/plugin-workspace-diff/
+COPY patches/ patches/
+COPY scripts/link-plugin-dev-sdk.mjs scripts/
+
RUN pnpm install --frozen-lockfile
FROM base AS build
WORKDIR /app
COPY --from=deps /app /app
COPY . .
-RUN pnpm --filter @paperclip/ui build
-RUN pnpm --filter @paperclip/server build
+RUN pnpm --filter @paperclipai/ui build
+RUN pnpm --filter @paperclipai/plugin-sdk build
+RUN pnpm --filter @paperclipai/server build
+RUN test -f server/dist/index.js || (echo "ERROR: server build output missing" && exit 1)
FROM base AS production
+ARG USER_UID=1000
+ARG USER_GID=1000
WORKDIR /app
-COPY --from=build /app /app
-RUN npm install --global --omit=dev @anthropic-ai/claude-code@latest @openai/codex@latest
+COPY --chown=node:node --from=build /app /app
+RUN npm install --global --omit=dev @anthropic-ai/claude-code@latest @openai/codex@latest opencode-ai \
+ && apt-get update \
+ && apt-get install -y --no-install-recommends openssh-client jq \
+ && rm -rf /var/lib/apt/lists/* \
+ && mkdir -p /paperclip \
+ && chown node:node /paperclip
+
+COPY scripts/docker-entrypoint.sh /usr/local/bin/
+RUN chmod +x /usr/local/bin/docker-entrypoint.sh
ENV NODE_ENV=production \
HOME=/paperclip \
@@ -36,11 +73,15 @@ ENV NODE_ENV=production \
SERVE_UI=true \
PAPERCLIP_HOME=/paperclip \
PAPERCLIP_INSTANCE_ID=default \
+ USER_UID=${USER_UID} \
+ USER_GID=${USER_GID} \
PAPERCLIP_CONFIG=/paperclip/instances/default/config.json \
- PAPERCLIP_DEPLOYMENT_MODE=local_trusted \
- PAPERCLIP_DEPLOYMENT_EXPOSURE=private
+ PAPERCLIP_DEPLOYMENT_MODE=authenticated \
+ PAPERCLIP_DEPLOYMENT_EXPOSURE=private \
+ OPENCODE_ALLOW_ALL_MODELS=true
VOLUME ["/paperclip"]
EXPOSE 3100
+ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["node", "--import", "./server/node_modules/tsx/dist/loader.mjs", "server/dist/index.js"]
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 00000000000..a63594a5150
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Paperclip AI
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/README.md b/README.md
index e38cb1bacf5..fe49f3d5cdf 100644
--- a/README.md
+++ b/README.md
@@ -6,7 +6,8 @@
Quickstart ·
Docs ·
GitHub ·
- Discord
+ Discord ·
+ Twitter
@@ -156,6 +157,115 @@ Paperclip handles the hard orchestration details correctly.
+## What's Under the Hood
+
+Paperclip is a full control plane, not a wrapper. Before you build any of this yourself, know that it already exists:
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ PAPERCLIP SERVER │
+│ │
+│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
+│ │Identity & │ │ Work & │ │ Heartbeat │ │Governance │ │
+│ │ Access │ │ Tasks │ │ Execution │ │& Approvals│ │
+│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
+│ │
+│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
+│ │ Org Chart │ │Workspaces │ │ Plugins │ │ Budget │ │
+│ │ & Agents │ │ & Runtime │ │ │ │ & Costs │ │
+│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
+│ │
+│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
+│ │ Routines │ │ Secrets & │ │ Activity │ │ Company │ │
+│ │& Schedules│ │ Storage │ │ & Events │ │Portability│ │
+│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
+└──────────────────────────────────────────────────────────────┘
+ ▲ ▲ ▲ ▲
+ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
+ │ Claude │ │ Codex │ │ CLI │ │ HTTP/web │
+ │ Code │ │ │ │ agents │ │ bots │
+ └───────────┘ └───────────┘ └───────────┘ └───────────┘
+```
+
+### The Systems
+
+
+
+
+
+**Identity & Access** — Two deployment modes (trusted local or authenticated), board users, agent API keys, short-lived run JWTs, company memberships, invite flows, and OpenClaw onboarding. Every mutating request is traced to an actor.
+
+
+
+
+**Org Chart & Agents** — Agents have roles, titles, reporting lines, permissions, and budgets. Adapter examples match the diagram: Claude Code, Codex, CLI agents such as Cursor/Gemini/bash, HTTP/webhook bots such as OpenClaw, and external adapter plugins. If it can receive a heartbeat, it's hired.
+
+
+
+
+
+
+**Work & Task System** — Issues carry company/project/goal/parent links, atomic checkout with execution locks, first-class blocker dependencies, comments, documents, attachments, work products, labels, and inbox state. No double-work, no lost context.
+
+
+
+
+**Heartbeat Execution** — DB-backed wakeup queue with coalescing, budget checks, workspace resolution, secret injection, skill loading, and adapter invocation. Runs produce structured logs, cost events, session state, and audit trails. Recovery handles orphaned runs automatically.
+
+
+
+
+
+
+**Workspaces & Runtime** — Project workspaces, isolated execution workspaces (git worktrees, operator branches), and runtime services (dev servers, preview URLs). Agents work in the right directory with the right context every time.
+
+
+
+
+**Governance & Approvals** — Board approval workflows, execution policies with review/approval stages, decision tracking, budget hard-stops, agent pause/resume/terminate, and full audit logging. You're the board — nothing ships without your sign-off.
+
+
+
+
+
+
+**Budget & Cost Control** — Token and cost tracking by company, agent, project, goal, issue, provider, and model. Scoped budget policies with warning thresholds and hard stops. Overspend pauses agents and cancels queued work automatically.
+
+
+
+
+**Routines & Schedules** — Recurring tasks with cron, webhook, and API triggers. Concurrency and catch-up policies. Each routine execution creates a tracked issue and wakes the assigned agent — no manual kick-offs needed.
+
+
+
+
+
+
+**Plugins** — Instance-wide plugin system with out-of-process workers, capability-gated host services, job scheduling, tool exposure, and UI contributions. Extend Paperclip without forking it.
+
+
+
+
+**Secrets & Storage** — Instance and company secrets, encrypted local storage, provider-backed object storage, attachments, and work products. Sensitive values stay out of prompts unless a scoped run explicitly needs them.
+
+
+
+
+
+
+**Activity & Events** — Mutating actions, heartbeat state changes, cost events, approvals, comments, and work products are recorded as durable activity so operators can audit what happened and why.
+
+
+
+
+**Company Portability** — Export and import entire organizations — agents, skills, projects, routines, and issues — with secret scrubbing and collision handling. One deployment, many companies, complete data isolation.
+
+
+
+
+
+
+
## What Paperclip is not
| | |
@@ -177,6 +287,16 @@ Open source. Self-hosted. No Paperclip account required.
npx paperclipai onboard --yes
```
+That quickstart path now defaults to trusted local loopback mode for the fastest first run. To start in authenticated/private mode instead, choose a bind preset explicitly:
+
+```bash
+npx paperclipai onboard --yes --bind lan
+# or:
+npx paperclipai onboard --yes --bind tailnet
+```
+
+If you already have Paperclip configured, rerunning `onboard` keeps the existing config in place. Use `paperclipai configure` to edit settings.
+
Or manually:
```bash
@@ -218,42 +338,79 @@ By default, agents run on scheduled heartbeats and event-based triggers (task as
## Development
```bash
-pnpm dev # Full dev (API + UI)
+pnpm dev # Full dev (API + UI, watch mode)
+pnpm dev:once # Full dev without file watching
pnpm dev:server # Server only
pnpm build # Build all
pnpm typecheck # Type checking
-pnpm test:run # Run tests
+pnpm test # Cheap default test run (Vitest only)
+pnpm test:watch # Vitest watch mode
+pnpm test:e2e # Playwright browser suite
pnpm db:generate # Generate DB migration
pnpm db:migrate # Apply migrations
```
+`pnpm test` does not run Playwright. Browser suites stay separate and are typically run only when working on those flows or in CI.
+
See [doc/DEVELOPING.md](doc/DEVELOPING.md) for the full development guide.
## Roadmap
-- ⚪ Get OpenClaw onboarding easier
-- ⚪ Get cloud agents working e.g. Cursor / e2b agents
-- ⚪ ClipMart - buy and sell entire agent companies
-- ⚪ Easy agent configurations / easier to understand
-- ⚪ Better support for harness engineering
-- ⚪ Plugin system (e.g. if you want to add a knowledgebase, custom tracing, queues, etc)
-- ⚪ Better docs
+- ✅ Plugin system (e.g. add a knowledge base, custom tracing, queues, etc)
+- ✅ Get OpenClaw / claw-style agent employees
+- ✅ companies.sh - import and export entire organizations
+- ✅ Easy AGENTS.md configurations
+- ✅ Skills Manager
+- ✅ Scheduled Routines
+- ✅ Better Budgeting
+- ✅ Agent Reviews and Approvals
+- ✅ Multiple Human Users
+- ⚪ Cloud / Sandbox agents (e.g. Cursor / e2b agents)
+- ⚪ Artifacts & Work Products
+- ⚪ Memory / Knowledge
+- ⚪ Enforced Outcomes
+- ⚪ MAXIMIZER MODE
+- ⚪ Deep Planning
+- ⚪ Work Queues
+- ⚪ Self-Organization
+- ⚪ Automatic Organizational Learning
+- ⚪ CEO Chat
+- ⚪ Cloud deployments
+- ⚪ Desktop App
+
+This is the short roadmap preview. See the full roadmap in [ROADMAP.md](ROADMAP.md).
+## Community & Plugins
+
+Find Plugins and more at [awesome-paperclip](https://github.com/gsxdsm/awesome-paperclip)
+
+## Telemetry
+
+Paperclip collects anonymous usage telemetry to help us understand how the product is used and improve it. No personal information, issue content, prompts, file paths, or secrets are ever collected. Private repository references are hashed with a per-install salt before being sent.
+
+Telemetry is **enabled by default** and can be disabled with any of the following:
+
+| Method | How |
+| -------------------- | ------------------------------------------------------- |
+| Environment variable | `PAPERCLIP_TELEMETRY_DISABLED=1` |
+| Standard convention | `DO_NOT_TRACK=1` |
+| CI environments | Automatically disabled when `CI=true` |
+| Config file | Set `telemetry.enabled: false` in your Paperclip config |
+
## Contributing
We welcome contributions. See the [contributing guide](CONTRIBUTING.md) for details.
-
-
## Community
- [Discord](https://discord.gg/m4HZY7xNG3) — Join the community
+- [Twitter / X](https://x.com/papercliping) — Follow updates and announcements
- [GitHub Issues](https://github.com/paperclipai/paperclip/issues) — bugs and feature requests
- [GitHub Discussions](https://github.com/paperclipai/paperclip/discussions) — ideas and RFC
diff --git a/ROADMAP.md b/ROADMAP.md
new file mode 100644
index 00000000000..d4036c3db94
--- /dev/null
+++ b/ROADMAP.md
@@ -0,0 +1,97 @@
+# Roadmap
+
+This document expands the roadmap preview in `README.md`.
+
+Paperclip is still moving quickly. The list below is directional, not promised, and priorities may shift as we learn from users and from operating real AI companies with the product.
+
+We value community involvement and want to make sure contributor energy goes toward areas where it can land.
+
+We may accept contributions in the areas below, but if you want to work on roadmap-level core features, please coordinate with us first in Discord (`#dev`) before writing code. Bugs, docs, polish, and tightly scoped improvements are still the easiest contributions to merge.
+
+If you want to extend Paperclip today, the best path is often the [plugin system](doc/plugins/PLUGIN_SPEC.md). Community reference implementations are also useful feedback even when they are not merged directly into core.
+
+## Milestones
+
+### ✅ Plugin system
+
+Paperclip should keep a thin core and rich edges. Plugins are the path for optional capabilities like knowledge bases, custom tracing, queues, doc editors, and other product-specific surfaces that do not need to live in the control plane itself.
+
+### ✅ Get OpenClaw / claw-style agent employees
+
+Paperclip should be able to hire and manage real claw-style agent workers, not just a narrow built-in runtime. This is part of the larger "bring your own agent" story and keeps the control plane useful across different agent ecosystems.
+
+### ✅ companies.sh - import and export entire organizations
+
+Reusable companies matter. Import/export is the foundation for moving org structures, agent definitions, and reusable company setups between environments and eventually for broader company-template distribution.
+
+### ✅ Easy AGENTS.md configurations
+
+Agent setup should feel repo-native and legible. Simple `AGENTS.md`-style configuration lowers the barrier to getting an agent team running and makes it easier for contributors to understand how a company is wired together.
+
+### ✅ Skills Manager
+
+Agents need a practical way to discover, install, and use skills without every setup becoming bespoke. The skills layer is part of making Paperclip companies more reusable and easier to operate.
+
+### ✅ Scheduled Routines
+
+Recurring work should be native. Routine tasks like reports, reviews, and other periodic work need first-class scheduling so the company keeps operating even when no human is manually kicking work off.
+
+### ✅ Better Budgeting
+
+Budgets are a core control-plane feature, not an afterthought. Better budgeting means clearer spend visibility, safer hard stops, and better operator control over how autonomy turns into real cost.
+
+### ✅ Agent Reviews and Approvals
+
+Paperclip should support explicit review and approval stages as first-class workflow steps, not just ad hoc comments. That means reviewer routing, approval gates, change requests, and durable audit trails that fit the same task model as the rest of the control plane.
+
+### ✅ Multiple Human Users
+
+Paperclip needs a clearer path from solo operator to real human teams. That means shared board access, safer collaboration, and a better model for several humans supervising the same autonomous company.
+
+### ⚪ Cloud / Sandbox agents (e.g. Cursor / e2b agents)
+
+We want agents to run in more remote and sandboxed environments while preserving the same Paperclip control-plane model. This makes the system safer, more flexible, and more useful outside a single trusted local machine.
+
+### ⚪ Artifacts & Work Products
+
+Paperclip should make outputs first-class. That means generated artifacts, previews, deployable outputs, and the handoff from "agent did work" to "here is the result" should become more visible and easier to operate.
+
+### ⚪ Memory / Knowledge
+
+We want a stronger memory and knowledge surface for companies, agents, and projects. That includes durable memory, better recall of prior decisions and context, and a clearer path for knowledge-style capabilities without turning Paperclip into a generic chat app.
+
+### ⚪ Enforced Outcomes
+
+Paperclip should get stricter about what counts as finished work. Tasks, approvals, and execution flows should resolve to clear outcomes like merged code, published artifacts, shipped docs, or explicit decisions instead of stopping at vague status updates.
+
+### ⚪ MAXIMIZER MODE
+
+This is the direction for higher-autonomy execution: more aggressive delegation, deeper follow-through, and stronger operating loops with clear budgets, visibility, and governance. The point is not hidden autonomy; the point is more output per human supervisor.
+
+### ⚪ Deep Planning
+
+Some work needs more than a task description before execution starts. Deeper planning means stronger issue documents, revisionable plans, and clearer review loops for strategy-heavy work before agents begin execution.
+
+### ⚪ Work Queues
+
+Paperclip should support queue-style work streams for repeatable inputs like support, triage, review, and backlog intake. That would make it easier to route work continuously without turning every system into a one-off workflow.
+
+### ⚪ Self-Organization
+
+As companies grow, agents should be able to propose useful structural changes such as role adjustments, delegation changes, and new recurring routines. The goal is adaptive organizations that still stay within governance and approval boundaries.
+
+### ⚪ Automatic Organizational Learning
+
+Paperclip should get better at turning completed work into reusable organizational knowledge. That includes capturing playbooks, recurring fixes, and decision patterns so future work starts from what the company has already learned.
+
+### ⚪ CEO Chat
+
+We want a lighter-weight way to talk to leadership agents, but those conversations should still resolve to real work objects like plans, issues, approvals, or decisions. This should improve interaction without changing the core task-and-comments model.
+
+### ⚪ Cloud deployments
+
+Local-first remains important, but Paperclip also needs a cleaner shared deployment story. Teams should be able to run the same product in hosted or semi-hosted environments without changing the mental model.
+
+### ⚪ Desktop App
+
+A desktop app can make Paperclip feel more accessible and persistent for day-to-day operators. The goal is easier access, better local ergonomics, and a smoother default experience for users who want the control plane always close at hand.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 00000000000..ccc4b6a03d2
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,8 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+Please report security vulnerabilities through GitHub's Security Advisory feature:
+[https://github.com/paperclipai/paperclip/security/advisories/new](https://github.com/paperclipai/paperclip/security/advisories/new)
+
+Do not open public issues for security vulnerabilities.
diff --git a/adapter-plugin.md b/adapter-plugin.md
new file mode 100644
index 00000000000..13994ba3b32
--- /dev/null
+++ b/adapter-plugin.md
@@ -0,0 +1,143 @@
+- Created branch: feat/external-adapter-phase1
+
+ I started phase 1 in the most merge-friendly way I could: small central changes, reusing existing registry patterns instead of inventing a whole new plugin system up front.
+
+ What I changed
+
+ 1. Server adapter registry is now mutable
+ Files:
+ - server/src/adapters/registry.ts
+ - server/src/adapters/index.ts
+
+ Added:
+ - registerServerAdapter(adapter)
+ - unregisterServerAdapter(type)
+ - requireServerAdapter(type)
+
+ Kept the existing built-in registry shape, but changed initialization so built-ins are registered into a mutable map on startup.
+
+ Why this is merge-friendly:
+ - existing built-in adapter definitions stay where they already are
+ - existing lookup helpers still exist
+ - no big architectural rewrite yet
+
+ 1. Runtime adapter validation moved to server routes
+ File:
+ - server/src/routes/agents.ts
+
+ Added:
+ - assertKnownAdapterType(...)
+
+ Used it in:
+ - /companies/:companyId/adapters/:type/models
+ - /companies/:companyId/adapters/:type/detect-model
+ - /companies/:companyId/adapters/:type/test-environment
+ - POST /companies/:companyId/agents
+ - POST /companies/:companyId/agent-hires
+ - PATCH /agents/:id when adapterType is touched
+
+ Why:
+ - shared schemas can now allow external adapter strings
+ - server becomes the real source of truth for “is this adapter actually registered?”
+
+ 1. Shared adapterType validation is now open-ended for inputs
+ Files:
+ - packages/shared/src/adapter-type.ts
+ - packages/shared/src/validators/agent.ts
+ - packages/shared/src/validators/access.ts
+ - packages/shared/src/index.ts
+
+ Changed input validation from hardcoded z.enum(AGENT_ADAPTER_TYPES) to:
+ - agentAdapterTypeSchema
+ - optionalAgentAdapterTypeSchema
+
+ These accept any non-empty string.
+
+ Important:
+ - I did not remove AGENT_ADAPTER_TYPES from constants
+ - I did not change the built-in type unions yet
+ - this keeps the change minimal and limits blast radius
+
+ So:
+ - input payloads can carry external adapter types
+ - actual acceptance still depends on server registry validation
+
+ 1. UI adapter registry is now mutable too
+ Files:
+ - ui/src/adapters/registry.ts
+ - ui/src/adapters/index.ts
+
+ Added:
+ - registerUIAdapter(adapter)
+ - unregisterUIAdapter(type)
+ - findUIAdapter(type)
+
+ Built-ins are still registered from the same file, same pattern as server.
+
+ 1. Began switching UI adapter lists toward the registry
+ Files:
+ - ui/src/adapters/metadata.ts
+ - ui/src/components/AgentConfigForm.tsx
+ - ui/src/pages/NewAgent.tsx
+
+ Changed:
+ - AgentConfigForm adapter list now comes from registered UI adapters via metadata helper
+ - NewAgent supported adapter set now derives from listUIAdapters()
+
+ Why:
+ - phase 1 should start reducing hardcoded UI lists
+ - but without rewriting every page at once
+
+ 1. Tests added first, then implementation
+ New tests:
+ - server/src/__tests__/adapter-registry.test.ts
+ - server/src/__tests__/agent-adapter-validation-routes.test.ts
+ - ui/src/adapters/registry.test.ts
+ - packages/shared/src/adapter-types.test.ts
+
+ Small test mock fix:
+ - server/src/__tests__/agent-skills-routes.test.ts
+
+ Current status
+
+ The branch is created and the phase-1 code is started.
+
+ I also followed TDD in spirit:
+ - wrote failing tests first for missing register/unregister APIs
+ - then implemented the registry changes
+
+ What is not finished yet
+
+ I have not finished the green/stabilization pass yet.
+
+ I still need to:
+ - run the targeted tests again after the implementation changes
+ - fix any TS / mocking fallout
+ - decide how far to take phase-1 UI wiring in this branch before stopping
+
+ Also, I intentionally did not yet touch the bigger hardcoded surfaces like:
+ - NewAgentDialog
+ - OnboardingWizard
+ - InviteLanding
+ - duplicated adapterLabels maps
+ - plugin manifest / plugin loader adapter contributions
+
+ That is deliberate.
+ For merge safety, I started with the smallest useful seam:
+ - dynamic server registry
+ - dynamic UI registry
+ - runtime validation based on registry
+ - first couple of UI consumers
+
+ One note
+ There was already an unrelated dirty change in:
+ - server/scripts/dev-watch.ts
+
+ I left that alone and did not make phase-1 changes there.
+
+ Recommended next move
+ I should keep going on this same branch and do the stabilization pass:
+ 1. rerun server/ui/shared targeted tests
+ 2. fix failures
+ 3. run typechecks
+ 4. then extend the same registry-driven approach to the next safest UI surfaces
diff --git a/bin/import-agents b/bin/import-agents
new file mode 100755
index 00000000000..cf3b5f5e760
--- /dev/null
+++ b/bin/import-agents
@@ -0,0 +1,116 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Auto-detect tsx path
+TSX=""
+for path in \
+ "./server/node_modules/.bin/tsx" \
+ "./node_modules/.bin/tsx" \
+ "$(which tsx 2>/dev/null || true)"
+do
+ if [ -x "$path" ]; then
+ TSX="$path"
+ break
+ fi
+done
+
+if [ -z "$TSX" ]; then
+ echo "❌ tsx not found. Install with: npm install -g tsx" >&2
+ exit 1
+fi
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+REPO_URL="${1:-}"
+shift || true
+
+if [ -z "$REPO_URL" ]; then
+ echo "Usage: import-agents [options]"
+ echo ""
+ echo "Options:"
+ echo " --company-id Company ID for agent creation"
+ echo " --github-token GitHub API token (optional)"
+ echo " --reports-to Agent ID to report to"
+ echo " --dry-run Preview without creating agents"
+ echo ""
+ echo "Example:"
+ echo " import-agents https://github.com/msitarzewski/agency-agents --dry-run"
+ exit 1
+fi
+
+echo "🚀 Paperclip Agent Importer"
+echo "============================"
+echo ""
+
+# Parse owner/repo from URL
+if [[ "$REPO_URL" =~ github\.com/([^/]+)/([^/]+) ]]; then
+ OWNER="${BASH_REMATCH[1]}"
+ REPO="${BASH_REMATCH[2]}"
+ echo "📦 Repository: $OWNER/$REPO"
+else
+ echo "❌ Invalid GitHub URL: $REPO_URL" >&2
+ exit 1
+fi
+
+# Step 1: Read GitHub repo
+echo ""
+echo "📖 Step 1: Fetching agent definitions..."
+"$TSX" "$SCRIPT_DIR/scripts/github-repo-reader.ts" "$OWNER/$REPO" "$@" > /tmp/import_step1.txt 2>&1
+
+if ! grep -q "Found" /tmp/import_step1.txt; then
+ echo "❌ Failed to read repository" >&2
+ cat /tmp/import_step1.txt >&2
+ exit 1
+fi
+
+AGENT_COUNT=$(grep -oP "Found \K\d+" /tmp/import_step1.txt || echo "0")
+echo "✅ Found $AGENT_COUNT agent(s)"
+
+if [ "$AGENT_COUNT" -eq 0 ]; then
+ echo "⚠️ No agents found. Exiting."
+ exit 0
+fi
+
+# Extract JSON
+sed -n '/---JSON---/,$p' /tmp/import_step1.txt | tail -n +2 > /tmp/import_agents.json
+
+# Step 2: Convert
+echo ""
+echo "🔧 Step 2: Converting to Paperclip format..."
+"$TSX" "$SCRIPT_DIR/scripts/agent-format-converter.ts" /tmp/import_agents.json > /tmp/import_step2.txt 2>&1
+
+if ! grep -q "Success:" /tmp/import_step2.txt; then
+ echo "❌ Conversion failed" >&2
+ cat /tmp/import_step2.txt >&2
+ exit 1
+fi
+
+SUCCESS_COUNT=$(grep -oP "Success: \K\d+" /tmp/import_step2.txt || echo "0")
+FAILED_COUNT=$(grep -oP "Failed: \K\d+" /tmp/import_step2.txt || echo "0")
+echo "✅ Converted: $SUCCESS_COUNT success, $FAILED_COUNT failed"
+
+# Extract converted agents
+sed -n '/---JSON---/,$p' /tmp/import_step2.txt | tail -n +2 > /tmp/import_converted.json
+
+# Step 3: Create agents (or dry-run)
+echo ""
+if echo "$@" | grep -q "\-\-dry-run"; then
+ echo "🔍 Step 3: DRY RUN — Preview only"
+ echo ""
+ echo "Agents that would be created:"
+ python3 -c "
+import json
+agents = json.load(open('/tmp/import_converted.json'))
+for a in agents[:10]:
+ print(f' • {a[\"name\"]} ({a[\"role\"]}) — {a[\"title\"]}')
+if len(agents) > 10:
+ print(f' ... and {len(agents)-10} more')
+" 2>/dev/null || echo " (install python3 for pretty output)"
+ echo ""
+ echo "💡 Remove --dry-run to actually create agents"
+else
+ echo "📝 Step 3: Creating agents via API..."
+ "$TSX" "$SCRIPT_DIR/scripts/import-agents.ts" "$REPO_URL" "$@"
+fi
+
+echo ""
+echo "🎉 Done!"
diff --git a/cli/CHANGELOG.md b/cli/CHANGELOG.md
index e72da8394e4..d261b8a85d6 100644
--- a/cli/CHANGELOG.md
+++ b/cli/CHANGELOG.md
@@ -1,5 +1,44 @@
# paperclipai
+## 0.3.1
+
+### Patch Changes
+
+- Stable release preparation for 0.3.1
+- Updated dependencies
+ - @paperclipai/adapter-utils@0.3.1
+ - @paperclipai/adapter-claude-local@0.3.1
+ - @paperclipai/adapter-codex-local@0.3.1
+ - @paperclipai/adapter-cursor-local@0.3.1
+ - @paperclipai/adapter-gemini-local@0.3.1
+ - @paperclipai/adapter-openclaw-gateway@0.3.1
+ - @paperclipai/adapter-opencode-local@0.3.1
+ - @paperclipai/adapter-pi-local@0.3.1
+ - @paperclipai/db@0.3.1
+ - @paperclipai/shared@0.3.1
+ - @paperclipai/server@0.3.1
+
+## 0.3.0
+
+### Minor Changes
+
+- Stable release preparation for 0.3.0
+
+### Patch Changes
+
+- Updated dependencies [6077ae6]
+- Updated dependencies
+ - @paperclipai/shared@0.3.0
+ - @paperclipai/adapter-utils@0.3.0
+ - @paperclipai/adapter-claude-local@0.3.0
+ - @paperclipai/adapter-codex-local@0.3.0
+ - @paperclipai/adapter-cursor-local@0.3.0
+ - @paperclipai/adapter-openclaw-gateway@0.3.0
+ - @paperclipai/adapter-opencode-local@0.3.0
+ - @paperclipai/adapter-pi-local@0.3.0
+ - @paperclipai/db@0.3.0
+ - @paperclipai/server@0.3.0
+
## 0.2.7
### Patch Changes
diff --git a/cli/README.md b/cli/README.md
new file mode 100644
index 00000000000..b23c32a69cf
--- /dev/null
+++ b/cli/README.md
@@ -0,0 +1,306 @@
+
+
+
+
+## What is Paperclip?
+
+# Open-source orchestration for zero-human companies
+
+**If OpenClaw is an _employee_, Paperclip is the _company_**
+
+Paperclip is a Node.js server and React UI that orchestrates a team of AI agents to run a business. Bring your own agents, assign goals, and track your agents' work and costs from one dashboard.
+
+It looks like a task manager — but under the hood it has org charts, budgets, governance, goal alignment, and agent coordination.
+
+**Manage business goals, not pull requests.**
+
+| | Step | Example |
+| ------ | --------------- | ------------------------------------------------------------------ |
+| **01** | Define the goal | _"Build the #1 AI note-taking app to $1M MRR."_ |
+| **02** | Hire the team | CEO, CTO, engineers, designers, marketers — any bot, any provider. |
+| **03** | Approve and run | Review strategy. Set budgets. Hit go. Monitor from the dashboard. |
+
+
+
+> **COMING SOON: Clipmart** — Download and run entire companies with one click. Browse pre-built company templates — full org structures, agent configs, and skills — and import them into your Paperclip instance in seconds.
+
+
+
+
+
+
+
Works with
+
OpenClaw
+
Claude Code
+
Codex
+
Cursor
+
Bash
+
HTTP
+
+
+
+If it can receive a heartbeat, it's hired.
+
+
+
+
+
+## Paperclip is right for you if
+
+- ✅ You want to build **autonomous AI companies**
+- ✅ You **coordinate many different agents** (OpenClaw, Codex, Claude, Cursor) toward a common goal
+- ✅ You have **20 simultaneous Claude Code terminals** open and lose track of what everyone is doing
+- ✅ You want agents running **autonomously 24/7**, but still want to audit work and chime in when needed
+- ✅ You want to **monitor costs** and enforce budgets
+- ✅ You want a process for managing agents that **feels like using a task manager**
+- ✅ You want to manage your autonomous businesses **from your phone**
+
+
+
+## Features
+
+
+
+
+
🔌 Bring Your Own Agent
+Any agent, any runtime, one org chart. If it can receive a heartbeat, it's hired.
+
+
+
🎯 Goal Alignment
+Every task traces back to the company mission. Agents know what to do and why.
+
+
+
💓 Heartbeats
+Agents wake on a schedule, check work, and act. Delegation flows up and down the org chart.
+
+
+
+
+
💰 Cost Control
+Monthly budgets per agent. When they hit the limit, they stop. No runaway costs.
+
+
+
🏢 Multi-Company
+One deployment, many companies. Complete data isolation. One control plane for your portfolio.
+
+
+
🎫 Ticket System
+Every conversation traced. Every decision explained. Full tool-call tracing and immutable audit log.
+
+
+
+
+
🛡️ Governance
+You're the board. Approve hires, override strategy, pause or terminate any agent — at any time.
+
+
+
📊 Org Chart
+Hierarchies, roles, reporting lines. Your agents have a boss, a title, and a job description.
+
+
+
📱 Mobile Ready
+Monitor and manage your autonomous businesses from anywhere.
+