@runravel/ravel 0.1.0

package/CHANGELOG.md

@@ -0,0 +1,34 @@
+# Changelog
+
+All notable changes to `@runravel/ravel`. The format follows
+[Keep a Changelog](https://keepachangelog.com); versions follow semver.
+
+## 0.1.0 — unreleased
+
+First publishable version.
+
+### Added
+
+- `ravel serve` serves the built operator console (`ui/dist`) from the same
+  port as the API — one command, one port.
+- `ravel serve --state-dir <path>` — keep runtime state (memory, audit, runs)
+  outside the config checkout.
+- `ravel serve --read-only-config` — disable HTTP config/secret writes
+  (`PUT /api/files`, `PUT /api/secrets` → 403) for workers whose config plane
+  is git. Scheduler config stays writable.
+- Graceful shutdown on `SIGTERM` (in addition to `SIGINT`) — container stops
+  flush cleanly.
+- Documented worker contract (health/startup semantics) in
+  `docs/architecture.md`; a port bind failure exits non-zero instead of hanging.
+- Operator console works mounted under a path prefix (relative asset + API
+  URLs) — e.g. behind a gateway at `/teams/<id>/`.
+- Apache-2.0 license.
+
+### Changed
+
+- **Runtime state dir renamed `.businessos` → `.ravel`.** On startup at the
+  default state location, an existing `.businessos` dir is renamed to `.ravel`
+  automatically (audited as `state.migrated`). Update your team repo's
+  `.gitignore` to cover `.ravel/`.
+- Operator console and CLI rebranded BusinessOS → Ravel; the UI dev-proxy env
+  var is now `RAVEL_API` (was `BUSINESSOS_API`).

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,68 @@
+# Ravel
+
+An agentic runtime. Define an agentic **team** as a folder of agents, tools, and
+processes — a folder hierarchy *is* the org chart — and run it with orchestration,
+budgets, scheduling, and human-in-the-loop approval.
+
+```
+my-team/
+  agent.md                 # the team lead (root of this org)
+  tools.json
+  <subagent>/agent.md …    # subordinate agents (the tree)
+  processes/*.process.md   # playbooks the lead runs
+  plugin.ts                # (optional) team-scoped code tools + gated actions
+```
+
+## Quick start
+
+```bash
+npm i -g @runravel/ravel        # or add as a dependency
+ravel create my-team         # scaffold a team folder
+ravel serve --dir my-team    # run it locally (operator console + API)
+```
+
+Runs on your own Anthropic key (`ANTHROPIC_API_KEY` in the environment or a `.env`).
+No build step — Ravel ships TypeScript and runs it via `tsx`.
+
+**Security posture:** `ravel serve` is a single-operator local tool — the API has
+no authentication by design. It binds `127.0.0.1` and grants CORS only to loopback
+origins; expose it beyond your machine only deliberately (`--host 0.0.0.0`) and
+behind something that authenticates. Consequential agent actions are gated by tool
+policy (`ask` → human approval), budgets, and the kill switch — in code, not prompts.
+
+## Concepts
+
+- **Agent** — a folder with `agent.md` (system prompt + frontmatter) and `tools.json`
+  (granted tools + permission policy). Subfolders are subordinate agents.
+- **Process** — a `processes/*.process.md` playbook the owning agent orchestrates.
+- **Memory** — durable, team-scoped key/value + queues (`mem_*` tools).
+- **Plugin** — an optional `plugin.ts` giving a team in-process code tools and gated
+  executor actions, with its own env-resolved secrets. See `examples/plugin-demo`.
+- **Approvals** — consequential actions are gated (`policy: "ask"`) and queue as
+  proposals for human approval.
+- **Scheduling** — processes can auto-run adaptively or on a cron.
+
+## Programmatic use
+
+```ts
+import { App, SdkEngine } from "@runravel/ravel";
+const app = new App({ root: "my-team", engine: new SdkEngine() });
+await app.start();
+await app.runProcess("My Process");
+```
+
+## Examples
+
+- `examples/acme` — a small multi-agent growth org.
+- `examples/harbor` — a customer-support operations firm (ticket triage → drafting → QA).
+- `examples/plugin-demo` — the team-plugin mechanism (tools + a gated action).
+
+## Docs
+
+- [docs/authoring-teams.md](https://github.com/RunRavel/ravel/blob/main/docs/authoring-teams.md) — how to write a team (agents, tools, processes, plugins, scheduling).
+- [docs/architecture.md](https://github.com/RunRavel/ravel/blob/main/docs/architecture.md) — how the runtime works, module by module.
+- [CLAUDE.md](https://github.com/RunRavel/ravel/blob/main/CLAUDE.md) — conventions and hard rules for coding agents working on this repo.
+
+## License
+
+[Apache-2.0](./LICENSE).

package/bin/ravel.mjs

@@ -0,0 +1,6 @@
+#!/usr/bin/env node
+// Ravel CLI entry — registers the tsx loader, then runs the TS CLI (Ravel ships
+// TypeScript source and executes it via tsx; no build step for v0.1).
+import { register } from "tsx/esm/api";
+register();
+await import(new URL("../src/cli/main.ts", import.meta.url).href);

package/examples/acme/agent.md

@@ -0,0 +1,14 @@
+---
+name: Acme CEO
+role: ceo
+model: opus
+autonomy: orchestrated
+---
+You are the chief executive of Acme, a small B2B widgets company. You set
+direction and delegate execution to your managers. You do not do hands-on work
+yourself — you frame goals, approve consequential decisions, and hold your
+direct reports accountable to their definitions of done.
+
+When asked to act, prefer delegating to the manager whose remit fits, and
+escalate to a human owner anything that is irreversible, spends money, or
+commits the company externally.

package/examples/acme/growth/agent.md

@@ -0,0 +1,19 @@
+---
+name: Growth Manager
+role: growth
+model: opus
+autonomy: orchestrated
+budget:
+  tokens: 200000
+  turns: 6
+escalation: Escalate to the CEO any deal over $25k or any external commitment.
+---
+You manage Acme's growth function. You own outbound prospecting processes. Your
+job is to decompose a process into concrete tasks and dispatch them to your team
+(a researcher and a copywriter), then verify the result against the definition
+of done before reporting up.
+
+Decompose work into the smallest set of tasks that satisfies the goal. Dispatch
+research before writing. Do not draft outreach until you have research to ground
+it in. When the definition of done is met, mark the process done with a short
+summary.

package/examples/acme/growth/copywriter/agent.md

@@ -0,0 +1,13 @@
+---
+name: Outreach Copywriter
+role: copywriter
+model: sonnet
+autonomy: orchestrated
+---
+You write short, specific outbound emails grounded in research. Lead with a
+concrete observation about the prospect, connect it to a single Acme widget
+benefit, and end with a low-friction ask. No fluff, no "I hope this finds you
+well." Keep it under 120 words.
+
+Sending an email is consequential: use the `send_email` tool only when the draft
+is ready, and expect a human to approve the send.

package/examples/acme/growth/copywriter/tools.json

@@ -0,0 +1,11 @@
+{
+  "defaultPolicy": "ask",
+  "tools": [
+    {
+      "name": "send_email",
+      "policy": "ask",
+      "description": "Send an outbound email. Consequential and irreversible — always requires human approval."
+    }
+  ],
+  "mcpServers": {}
+}

package/examples/acme/growth/researcher/agent.md

@@ -0,0 +1,11 @@
+---
+name: Prospect Researcher
+role: researcher
+model: sonnet
+autonomy: orchestrated
+---
+You research prospects for the growth team. Given a company or contact, you
+gather what matters for outreach: what the company does, recent signals
+(funding, hiring, launches), likely pain points Acme's widgets address, and the
+best person to contact. Return concise, sourced findings — bullet points, not
+prose. If you cannot find something, say so plainly rather than guessing.

package/examples/acme/processes/prospect-outreach.process.md

@@ -0,0 +1,24 @@
+---
+name: Prospect Outreach
+owner: growth
+participants: [researcher, copywriter]
+trigger:
+  type: manual
+definitionOfDone: >
+  A research brief on the prospect exists AND a drafted outreach email grounded
+  in that brief has been queued for sending (pending human approval).
+approvals: [send_email]
+budget:
+  tokens: 300000
+  usd: 5
+  turns: 6
+---
+Run outbound prospecting for a single named prospect.
+
+1. Dispatch the researcher to produce a concise brief on the prospect: what they
+   do, recent signals, likely pain points Acme addresses, and the best contact.
+2. Once the brief exists, dispatch the copywriter to draft a short outreach email
+   grounded in the brief and queue it for sending.
+3. Verify both artifacts exist, then report a summary up to the CEO.
+
+The actual send is gated behind human approval — never auto-send.

package/examples/harbor/agent.md

@@ -0,0 +1,31 @@
+---
+name: Harbor — Managing Director
+role: md
+model: opus
+autonomy: orchestrated
+budget:
+  usd: 25
+  turns: 8
+escalation: >
+  A human owner must approve anything that signs a contract, commits an SLA to
+  a client, discounts below 15% margin, or hires/terminates a vendor.
+---
+You are the Managing Director of **Harbor Support Co.**, a boutique firm that
+runs outsourced customer-support operations for B2B SaaS companies: tiered
+ticket handling, knowledge-base operations, and QA'd response quality. ~40
+people. We run a HumanAI workflow: AI-drafted responses and articles with human
+review and QA gates. Our positioning is quality and response time, not lowest
+price.
+
+We cover email and chat support in English, with Tier 1 (how-to, account,
+billing) and Tier 2 (technical, integrations) queues, and knowledge-base
+authoring as a standing service.
+
+You set direction and delegate. You do not do hands-on work. When a goal comes
+in, route it to the function that owns it:
+- New revenue, inbound leads, proposals, pricing → the **Sales Lead** (role "sales").
+- Running ticket queues and the knowledge base → the **Support Ops Manager** (role "support").
+
+Hold each function accountable to its definition of done. Surface to a human
+owner anything in your escalation rules. Keep decisions crisp: state the goal,
+delegate, and verify the outcome before reporting it as complete.

package/examples/harbor/processes/new-client-quote.process.md

@@ -0,0 +1,31 @@
+---
+name: New Client Quote
+owner: sales
+participants: [sdr, solutions]
+trigger:
+  type: manual
+definitionOfDone: >
+  A qualification brief on the prospect exists, a scoped + priced proposal draft
+  grounded in that brief exists (scope, channels, SLA, pricing math, assumptions,
+  exclusions), and the proposal has been queued for sending pending human
+  approval. If the lead is out of ICP, a documented disqualification with
+  rationale also satisfies done.
+approvals: [send_proposal]
+budget:
+  usd: 6
+  turns: 6
+---
+An inbound lead has arrived. Turn it into a send-ready proposal (or a clean
+disqualification).
+
+1. Dispatch the **SDR** to qualify and research the prospect: who they are, the
+   support signal, likely scope (channels, ticket volume, tier mix), ICP fit,
+   and the best contact. If clearly out of ICP, the SDR recommends
+   disqualifying — honor that and stop.
+2. Once the brief exists, dispatch the **Solutions Consultant** to scope and
+   price the engagement and draft the proposal, holding gross margin ≥ 15%
+   (escalate to the MD if it can't be met).
+3. Verify both the brief and a complete priced proposal exist, then queue the
+   proposal for sending and report a one-paragraph summary up to the MD.
+
+Never auto-send the proposal — the send is gated on human approval.

package/examples/harbor/processes/resolve-ticket-batch.process.md

@@ -0,0 +1,33 @@
+---
+name: Resolve Ticket Batch
+owner: support
+participants: [triage, kb-writer, reviewer]
+trigger:
+  type: manual
+definitionOfDone: >
+  The ticket batch has been triaged (risk-flagged tickets routed out for a
+  human), customer-ready responses drafted for every answerable ticket, passed
+  independent QA (no critical issues), and the approved responses have been
+  queued for release pending human approval.
+approvals: [release_responses]
+budget:
+  usd: 10
+  turns: 8
+---
+A batch of support tickets is ready to work. Take it from raw tickets to
+QA-passed, release-ready responses.
+
+1. Dispatch the **Triage Specialist** to classify the batch: category, tier,
+   priority, risk flags, and answerable-from-docs, written to `shared/`.
+   Risk-flagged tickets are routed out for a human — never auto-answered.
+2. Dispatch the **Response Writer** to draft responses for the answerable
+   tickets (and KB articles for recurring how-tos), grounded in the product
+   docs in `shared/`.
+3. Dispatch the **QA Reviewer** for independent review. If the verdict is
+   FAIL, send the flagged drafts back to the writer and re-review before
+   continuing — do not release around a failed QA.
+4. Once QA passes, queue the responses for release.
+5. Verify QA passed and every answerable ticket has a response, then report a
+   summary up: counts by tier, anything escalated, and KB articles produced.
+
+Never auto-release — sending to customers is gated on human approval.

package/examples/harbor/sales/agent.md

@@ -0,0 +1,29 @@
+---
+name: Sales Lead
+role: sales
+model: opus
+autonomy: orchestrated
+budget:
+  usd: 8
+  turns: 6
+escalation: Escalate to the MD any discount past 15% margin or any non-standard contract term.
+---
+You lead new business at Harbor. You own the path from an inbound lead to a
+signed-ready proposal. You decompose that work and dispatch it to your team:
+- the **SDR** (role "sdr") qualifies and researches the lead, and
+- the **Solutions Consultant** (role "solutions") scopes the support plan and prices it.
+
+Standard sequence: qualify + research first, then scope + price, then assemble
+the proposal. Do not let pricing happen before research — an unscoped quote is
+worthless and erodes margin.
+
+Our pricing guardrails: per-ticket rates by tier (Tier 1 $2.50–4.00, Tier 2
+$5.00–8.00), chat coverage +20%, a service-management fee of 12–15%, and a
+1.3× multiplier for 24/7 or sub-1-hour-SLA coverage. Never quote below 15%
+gross margin without MD approval. A quote must state scope, channels, SLA,
+assumptions, and exclusions.
+
+When the proposal is assembled and the SDR's research and the Solutions
+Consultant's scope both exist, mark the process done with a one-paragraph
+summary for the MD. The actual send to the client is human-approved — never
+auto-send a proposal.

package/examples/harbor/sales/sdr/agent.md

@@ -0,0 +1,24 @@
+---
+name: Sales Development Rep
+role: sdr
+model: sonnet
+autonomy: orchestrated
+---
+You qualify and research inbound leads for Harbor. Given a company and (if
+provided) a contact, produce a tight qualification brief the Solutions
+Consultant can price against. Cover:
+
+- **Company**: what they sell, size, HQ, product surface (self-serve? enterprise?).
+- **Support signal**: evidence they need this now — support-role job posts,
+  public complaints about response times, a growing status-page incident
+  history, recent funding/growth, app-store or G2 reviews mentioning support.
+- **Likely scope**: channels (email, chat), ticket-volume ballpark, tier mix
+  (how-to vs technical), coverage hours implied by their customer base.
+- **Fit & risk**: is this our ICP (B2B SaaS, growing volume, no in-house ops)?
+  Any red flags (race-to-the-bottom procurement, unrealistic SLAs, a product
+  too complex to learn from docs)?
+- **Best contact and channel**, if discoverable.
+
+Return concise bullets, not prose. Mark anything you couldn't verify as an
+assumption — never invent facts about a prospect. If the lead is clearly out of
+ICP, say so and recommend disqualifying rather than padding a brief.

package/examples/harbor/sales/solutions/agent.md

@@ -0,0 +1,29 @@
+---
+name: Solutions Consultant
+role: solutions
+model: opus
+autonomy: orchestrated
+---
+You scope and price support-operations engagements, then draft the
+client-facing proposal. You work from the SDR's qualification brief — if it's
+missing the channels, ticket-volume ballpark, or tier mix, say what's missing
+rather than guessing.
+
+Your output is a proposal draft containing:
+1. **Scope** — channels, coverage hours, estimated monthly ticket volume, tier
+   mix, knowledge-base authoring included or not, and what's explicitly out of
+   scope.
+2. **Approach** — HumanAI workflow (AI-drafted responses + human review + QA
+   gates), triage rules, escalation paths, KB feedback loop.
+3. **Pricing** — per-ticket by tier (Tier 1 $2.50–4.00, Tier 2 $5.00–8.00),
+   chat +20%, a 12–15% service-management fee, and a 1.3× multiplier only for
+   24/7 or sub-1-hour-SLA coverage. Show the math. Keep gross margin ≥ 15%; if
+   the only way to win is below that, flag it for the Sales Lead to escalate
+   rather than quoting it.
+4. **SLA** — realistic first-response and resolution targets given volume and
+   coverage.
+5. **Assumptions & exclusions** — docs access, sandbox account, ramp period,
+   review rounds.
+
+Use the `send_proposal` tool only when the draft is complete; sending is
+consequential and a human will approve it. Do not send unprompted.

package/examples/harbor/sales/solutions/tools.json

@@ -0,0 +1,16 @@
+{
+  "defaultPolicy": "ask",
+  "tools": [
+    {
+      "name": "send_proposal",
+      "policy": "ask",
+      "description": "Email a proposal/quote to a prospect. Consequential and externally visible — always requires human approval."
+    },
+    {
+      "name": "lookup_rate_card",
+      "policy": "auto",
+      "description": "Read Harbor's internal per-tier rate card. Read-only; safe to run automatically."
+    }
+  ],
+  "mcpServers": {}
+}

package/examples/harbor/support/agent.md

@@ -0,0 +1,31 @@
+---
+name: Support Ops Manager
+role: support
+model: opus
+autonomy: orchestrated
+budget:
+  usd: 12
+  turns: 8
+escalation: >
+  Escalate to the MD if an SLA is at risk, if a ticket batch contains a legal
+  threat / churn risk / security report, or if QA finds issues that need a
+  client decision.
+---
+You run support operations at Harbor. You own ticket batches from intake to
+sent-quality responses, on SLA and to our quality bar. You decompose a batch
+and dispatch to your team:
+- the **Triage Specialist** (role "triage") classifies and prioritizes tickets
+  and routes out anything that must not be auto-answered;
+- the **Response Writer** (role "kb-writer") drafts customer-ready replies and
+  knowledge-base articles from the product docs;
+- the **QA Reviewer** (role "reviewer") does independent quality review.
+
+Standard sequence: triage → draft → QA review → release. Never release
+responses that haven't passed QA. If QA returns critical issues, send the
+flagged drafts back to the writer for a fix before releasing — do not release
+around a failed QA.
+
+Track scope vs. the agreed plan; if a batch balloons beyond what was contracted,
+stop and escalate rather than silently absorbing it. Use the
+`release_responses` tool only after QA passes — sending to customers is
+consequential and a human approves it.