From ef4d64cf9aec9868b4270ed5f7333ec72c3c617b Mon Sep 17 00:00:00 2001 From: Ivan Pasichnyk Date: Fri, 1 May 2026 21:24:39 -0700 Subject: [PATCH] refactor: split packs out of engine repo (one repo per pack) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The seed pack at experiences/d49e0997/ moved to its own public repo: https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot Why one-repo-per-pack: - Authors own their pack lifecycle — issues, license, versioning, attribution — without coordinating with the engine repo. - Engine repo stays focused on the runtime; ships zero packs. - Future authors put their packs under their own GitHub handles; no PR-to-anthroos/openexp dance. - Pack-naming convention `exp-` makes a future automated registry index trivial: scan known orgs for repos prefixed `exp-`, aggregate `meta.yaml` summaries. What changed in this repo: - Removed `experiences/d49e0997/` entirely (4 files, 478 lines). History preserved in git log; canonical artifact lives in the new pack repo. - README.md "Publishing an Experience": new layout describes `exp-/` repo shape; install command now `git clone ` + symlink instead of `cp -r openexp/experiences/`. - README.md "Status": seed-published reference now points to the new pack repo. - docs/roadmap.md Section 4 (Marketplace browse + install): - "Public catalog" row reframed — catalog is the set of `exp-*` repos, listed at openexp.ai/use, with the seed as reference. - New row "Automated catalog index" (❌ today) — explicit gap. - "Install one pack" command updated to git-clone + symlink form. - docs/roadmap.md "What's shipped end-to-end today": demo path updated to clone the pack repo instead of copying from engine repo. - docs/skill-architecture.md "Storage vs install" table: storage is now `github.com//exp-`, not `experiences//`. Install flow rewritten with the clone+symlink steps. - docs/publishing-a-pack.md (new) — author guide. Schema, anonymization rules, why the per-pack repo split, how to announce a new pack (issue on anthroos/openexp). Existing user installs continue to work — install paths (`~/.claude/skills/openexp::/`) are unchanged. Only the source-of-clone moves from the engine repo to the pack repo. --- README.md | 17 +- docs/publishing-a-pack.md | 80 +++++ docs/roadmap.md | 16 +- docs/skill-architecture.md | 28 +- experiences/d49e0997/README.md | 35 -- experiences/d49e0997/SKILL.md | 97 ------ experiences/d49e0997/meta.yaml | 45 --- .../d49e0997/trajectory.anonymized.yaml | 301 ------------------ 8 files changed, 113 insertions(+), 506 deletions(-) create mode 100644 docs/publishing-a-pack.md delete mode 100644 experiences/d49e0997/README.md delete mode 100644 experiences/d49e0997/SKILL.md delete mode 100644 experiences/d49e0997/meta.yaml delete mode 100644 experiences/d49e0997/trajectory.anonymized.yaml diff --git a/README.md b/README.md index 0fd8b55..00428d6 100644 --- a/README.md +++ b/README.md @@ -89,17 +89,19 @@ You run both prompts inside your own Claude Code, against your own Qdrant. Nothi ## Publishing an Experience -A published experience is four files in a UUID-named directory (schema v3, 2026-04-27): +A published experience is its **own GitHub repo** (one repo per pack), containing four files: ``` -experiences// +exp-/ ├── meta.yaml # facts only: id, outcome label, duration, category tokens, license ├── trajectory.anonymized.yaml # raw ordered timeline of N steps, anonymized -├── README.md # human-readable face for the marketplace +├── README.md # human-readable face for the catalog └── SKILL.md # Claude entry point — read first when skill is invoked ``` -`meta.yaml` shape (abridged from seed `d49e0997`): +Each pack has its own repo so authors own their content (issues, license, versioning), and the engine repo stays focused on the runtime. See [`docs/publishing-a-pack.md`](docs/publishing-a-pack.md) for the author guide. + +`meta.yaml` shape (abridged from the seed pack [`exp-inbound-acquisition-with-free-pilot`](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot)): ```yaml pack: @@ -137,7 +139,8 @@ Drop the pack into `~/.claude/skills/openexp::/` (rename the direc ```bash # Install the seed pack as a skill -cp -r ~/openexp/experiences/d49e0997 \ +git clone https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot.git +ln -s "$PWD/exp-inbound-acquisition-with-free-pilot" \ ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot ``` @@ -149,7 +152,7 @@ Two layers of identity: See `docs/skill-architecture.md` for the full naming convention, install flow, and design rationale. -The `experiences/` directory in this repo is the seed of an eventual marketplace. The publication format works; seeds will accumulate. A directory of installable experiences is the eventual surface, not a built product today. +This engine repo is the runtime — it does not bundle packs. Each published pack lives in its own repo (see the [seed pack](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot) as the reference shape). A web catalog at `openexp.ai` aggregates published packs; an automated registry index is on the roadmap. A directory of installable experiences is the eventual surface, not a built product today. ## MCP Tools @@ -221,7 +224,7 @@ Environment variables (`.env`): ## Status -**Pilot. Architecture freeze landed 2026-04-26.** First experience seed published: `experiences/d49e0997/` — a 57-day inbound acquisition that closed at grade 1.0 (author's own assessment), anonymized to category tokens. +**Pilot. Architecture freeze landed 2026-04-26.** First experience seed published as a standalone repo: [`exp-inbound-acquisition-with-free-pilot`](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot) — a 57-day inbound acquisition that closed at grade 1.0 (author's own assessment), anonymized to category tokens. Honest about what isn't done: - The marketplace UI is just a directory in this repo. No web surface yet. diff --git a/docs/publishing-a-pack.md b/docs/publishing-a-pack.md new file mode 100644 index 0000000..e4b5682 --- /dev/null +++ b/docs/publishing-a-pack.md @@ -0,0 +1,80 @@ +# Publishing an OpenExp Pack + +> Each pack is its own GitHub repo. This guide is for authors who want to publish. + +## TL;DR + +``` +github.com//exp-/ +├── meta.yaml # facts only — id, outcome, duration, category tokens +├── trajectory.anonymized.yaml # raw ordered timeline, anonymized +├── README.md # human-readable face for the catalog +└── SKILL.md # Claude entry point +``` + +That's the whole shape. Reference: [`anthroos/exp-inbound-acquisition-with-free-pilot`](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot). + +## Why one repo per pack + +The OpenExp engine (`anthroos/openexp`) is the **runtime**. It ships zero packs. Packs live in their own repos so: + +1. **Authors own their content.** Issues, license, versioning, attribution — all on the author's repo, not negotiated through the engine. +2. **Lifecycles are independent.** A bug fix to a pack doesn't ship an engine release. An engine refactor doesn't churn pack repos. +3. **Discovery is by `exp-*` repo naming + `openexp.ai` catalog.** A future automated registry index will scan `exp-*` repos under known orgs and aggregate their `meta.yaml` summaries. + +## Steps + +### 1. Run the publishing pipeline + +Inside your own Claude Code session, against your own Qdrant collection. Two prompts: + +1. **`prompts/anonymize.md`** — replaces counterparty identity with category tokens (e.g. ``, ``). Author identity stays public — it signs the pack. +2. **`prompts/extract_experience.md`** — produces `meta.yaml` (facts only) from the anonymized trajectory plus the terminal outcome label. + +Output: four files matching the shape above. + +### 2. Create the repo + +Repo name: `exp-` where `` is the same slug that appears in the install skill name (`openexp::`). Public, MIT (or whatever license you declare in `meta.yaml`). + +Suggested topics: `openexp`, `openexp-pack`, `experience-pack`, plus domain-specific tags (e.g. `b2b-sales`, `mlops`, `incident-response`). + +Suggested description: one sentence — outcome label, duration, category. *"Inbound B2B acquisition trajectory — 57 days, closed_won. An OpenExp experience pack."* + +Homepage: `https://openexp.ai/`. + +### 3. Push the four files + +```bash +git init -b main +git add meta.yaml trajectory.anonymized.yaml README.md SKILL.md +git commit -m "Initial commit — pack format v3" +git remote add origin git@github.com:/exp-.git +git push -u origin main +``` + +### 4. Announce + +Open an issue on `anthroos/openexp` titled `pack: /` with a link. The catalog at `openexp.ai/use` is hand-maintained today; the issue is the request to add yours. + +## Schema + +See `README.md` (the engine repo's, you're reading it from there) section "Publishing an Experience" for the `meta.yaml` shape and the rationale behind shipping raw (no `applies_when`, no summary, no grade reason). + +## Anonymization + +The hard rule: **never name a real counterparty or platform.** Replace with category tokens: + +- People: ``, ``, ``, `` +- Companies: by category, never by name — ``, `` +- Tools/platforms: ``, ``, `` +- Money: ``, `` +- Geography: ``, `` + +A reader with deep domain knowledge may still triangulate identity from the trajectory shape. That's an open problem; the `prompts/anonymize.md` reverse-identification rule (industry / role / geography too narrow → generalize) is the current best-effort defence. + +Author identity is public on purpose — like authorship on a research paper. Counterparty identity stays anonymized. + +## License + +Pack content is under whatever license you declare in `meta.yaml` (default: MIT). Engine code is MIT. diff --git a/docs/roadmap.md b/docs/roadmap.md index a215f36..530c238 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -49,9 +49,10 @@ Legend: | Capability | Status | Today | |---|---|---| -| Public catalog | 🟡 | The catalog **is** the GitHub repo (`anthroos/openexp/experiences/`). Site `openexp.ai/use` lists currently published packs | -| Browsable filter UI ("show me sales packs that closed in <30 days") | ❌ | Today: read the file list, open `meta.yaml` to inspect tokens | -| Install one pack | ✅ | `cp -r openexp/experiences/ ~/.claude/skills/openexp::/` — auto-discovered by Claude Code | +| Public catalog | 🟡 | Each pack is its own GitHub repo named `exp-`. Site `openexp.ai/use` lists currently published packs. Reference seed: [`anthroos/exp-inbound-acquisition-with-free-pilot`](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot) | +| Browsable filter UI ("show me sales packs that closed in <30 days") | ❌ | Today: read the catalog list, open each pack's `meta.yaml` to inspect tokens | +| Automated catalog index (registry of all `exp-*` repos with `meta.yaml` summaries) | ❌ | Today: catalog is a hand-maintained list on `openexp.ai`. Future: a YAML index that `openexp-use` can read | +| Install one pack | ✅ | `git clone && ln -s "$PWD/" ~/.claude/skills/openexp::` — auto-discovered by Claude Code | | Install the `openexp-use` skill that knows how to apply any pack | ✅ | `git clone anthroos/claude-skills` + symlink. One-time, applies to all packs | | Search "is there a pack relevant to my situation?" | 🟡 | The `openexp-use` skill does this — discovers all installed packs and matches against the user's situation. Across-machines / public-marketplace search = ❌ | @@ -128,11 +129,14 @@ If you want to see the project work right now, this is the path: 1. **Install:** ``` + # One-time: the universal applier git clone https://github.com/anthroos/claude-skills.git ln -s ~/claude-skills/skills/core/openexp-use ~/.claude/skills/openexp-use - git clone https://github.com/anthroos/openexp.git - cp -r openexp/experiences/d49e0997 \ - ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot/ + + # Per pack: the pack itself + git clone https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot.git + ln -s "$PWD/exp-inbound-acquisition-with-free-pilot" \ + ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot ``` 2. **Restart Claude Code** — both the pack and the `openexp-use` skill auto-discover. 3. **Describe a situation** in your own words. The `openexp-use` skill discovers installed packs, reads each `meta.yaml` + `trajectory.anonymized.yaml`, judges fit, and replies with a cited `relative_day` from the matching trajectory. diff --git a/docs/skill-architecture.md b/docs/skill-architecture.md index 70a91cd..5b9b2fe 100644 --- a/docs/skill-architecture.md +++ b/docs/skill-architecture.md @@ -41,38 +41,36 @@ openexp::/ **Why no `experience.yaml`?** Earlier schemas (v2) shipped a wrapper artifact with `applies_when`, `searchable_summary`, and `grade_reason`. Those fields baked the publisher's read of the timeline into the pack — one Claude's interpretation, frozen at publish time. Schema v3 (2026-04-27) drops that wrapper and ships **raw**: `meta.yaml` carries facts only (outcome label, category tokens, structural counts), and the reader's Claude derives `applies_when` on the fly against the reader's actual situation. Different readers, different contexts, different inferences from the same trajectory. -Inside the canonical OpenExp repo, packs live at `experiences//`. The UUID-only directory is the **storage** form. The skill-namespaced directory is the **install** form. +Each published pack is its own GitHub repo named `exp-` (e.g. [`exp-inbound-acquisition-with-free-pilot`](https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot)). The repo is the **storage** form. The `~/.claude/skills/openexp::/` directory on the user's machine is the **install** form. ### Storage vs install | Layer | Path | Purpose | |-------|------|---------| -| **Storage** | `experiences//` (UUID-only, in repo) | Canonical artifact, version-controlled, anonymized | -| **Install** | `~/.claude/skills/openexp::/` | What a user copies into their Claude Code installation | +| **Storage** | `github.com//exp-` (one repo per pack) | Canonical artifact, version-controlled, anonymized; carries its own `meta.yaml` UUID | +| **Install** | `~/.claude/skills/openexp::/` | What a user symlinks into their Claude Code installation | Reasons for the split: -- UUID is stable and collision-free; it's the canonical ID across all systems. +- Each author owns their pack's lifecycle — issues, license, versioning — without coordinating with the engine repo. +- UUID inside `meta.yaml` is stable and collision-free; it's the canonical ID across all systems even if the slug changes. - Skill-namespaced name is presentation — what users see in their skill list. -- Renaming the slug never breaks the canonical reference. +- The engine repo (`anthroos/openexp`) stays focused on the runtime and ships zero packs. ## Install flow -A user installs a published experience pack by copying the directory into their Claude Code skill directory under the skill-namespaced name: +A user installs a published experience pack by cloning its repo and symlinking it into their Claude Code skill directory under the skill-namespaced name: ```bash -# Example: Ivan publishes to a public mirror, user installs. -cd ~/.claude/skills/ -git clone https://github.com/anthroos/openexp-experience-ivan-acquisition \ - openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot -``` - -Or, if the canonical pack lives in this repo and the user wants the seed: +# Clone the pack repo +git clone https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot.git -```bash -cp -r ~/openexp/experiences/d49e0997 \ +# Symlink under the skill-namespaced name +ln -s "$PWD/exp-inbound-acquisition-with-free-pilot" \ ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot ``` +(`cp -r` works too if the user wants a copy detached from upstream updates.) + Claude Code auto-discovers the skill on next session start. No registration step. ## Invocation flow diff --git a/experiences/d49e0997/README.md b/experiences/d49e0997/README.md deleted file mode 100644 index a6a764e..0000000 --- a/experiences/d49e0997/README.md +++ /dev/null @@ -1,35 +0,0 @@ -# Experience d49e0997 — Inbound Acquisition Trajectory - -**Author:** Ivan Pasichnyk (`ivan-pasichnyk`) -**Outcome label:** `closed_won` at `day_+57` -**Duration:** 57 days · 26 steps -**License:** MIT - -## What is published - -A 57-day inbound B2B acquisition arc, anonymized step by step. The pack ships **raw**: the timeline as it happened, plus a facts-only `meta.yaml`. There is **no `applies_when`**, **no summary**, **no author grade reason**. Those are interpretations and are deliberately omitted — the reader's Claude derives match from the trajectory on the fly. - -## Files - -- `meta.yaml` — facts only (id, outcome label, duration, category tokens, license) -- `trajectory.anonymized.yaml` — the timeline (26 ordered steps from `relative_day: 0` to `relative_day: +57`) -- `SKILL.md` — Claude entry point - -Counterparty identity replaced with category tokens (``, ``, ``, ``, etc.). Author identity is public — it signs the pack. - -## How to install - -```bash -git clone https://github.com/anthroos/openexp.git -cp -r openexp/experiences/d49e0997 \ - ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot/ -``` - -Auto-discovered on next Claude Code session. To use the pack, install the `openexp-use` Claude Code skill alongside it (one-time setup, applies to all packs): - -```bash -git clone https://github.com/anthroos/claude-skills.git -ln -s ~/claude-skills/skills/core/openexp-use ~/.claude/skills/openexp-use -``` - -Then describe your situation in your own words — `openexp-use` will discover this pack, read its trajectory, and reply with a cited `relative_day`. diff --git a/experiences/d49e0997/SKILL.md b/experiences/d49e0997/SKILL.md deleted file mode 100644 index 5f32d1f..0000000 --- a/experiences/d49e0997/SKILL.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -name: openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot -description: Use Ivan Pasichnyk's published experience pack — a 57-day inbound B2B acquisition trajectory that closed (outcome label closed_won, day +57). Counterparty redacted to category tokens. Invoke when the user is running a similar acquisition motion (inbound discovery from a counterparty technical decision-maker, free pilot work before contract, local-jurisdiction e-signing) and wants to map their own arc against a real trajectory step by step. The pack publishes raw: no pre-baked applies_when, no summary, no author grade — the reader's Claude derives match from `trajectory.anonymized.yaml` on the fly. ---- - -# OpenExp Experience — Ivan Pasichnyk · Inbound Acquisition Trajectory - -You have access to a published experience pack authored by **Ivan Pasichnyk** (handle: `ivan-pasichnyk`). The pack ships **raw**: an anonymized 26-step trajectory plus a facts-only `meta.yaml`. There is **no `applies_when`**, **no `searchable_summary`**, **no author grade or grade reason**. Those are interpretations. They belong to the reader, not the publisher. - -## Why raw - -The publisher's interpretation is one Claude's read of the timeline at the moment of publication, biased by what worked for that one author at that one moment. Different readers have different contexts and will draw different signals from the same events. So the publisher hands over the timeline; the reader's Claude does the matching, on the fly, against the reader's actual situation. - -## How to use this pack - -1. **Read `meta.yaml` first.** Facts only: outcome label (`closed_won`), `closed_at: day_+57`, `duration_days`, `step_count`, `category_tokens` that appear in the timeline. -2. **Read `trajectory.anonymized.yaml`** — 26 ordered steps from `relative_day: 0` (inbound discovery) to `relative_day: +57` (contract signed both sides). -3. **Derive match on the user's actual situation.** Look at the category tokens in `meta.yaml` and the structure of the trajectory. Decide whether the user's case is similar enough that step-level reference is useful. **You do the matching here — the pack does not pre-declare when it applies.** -4. **Map the user's situation to one specific `relative_day`.** Find the closest step in the trajectory to where the user is in their own arc. -5. **Cite by day with attribution.** Frame as "in Ivan's trajectory, day +X was…", never "the rule is…". - -## Output style — DEFAULT QUIET MODE - -Default reply mode is normal conversation, not a teleprompter. Most replies should be **≤3 short sentences**, written the way a senior peer would talk — not as a structured report. - -**Do not, by default:** - -- dump match tables, scoring grids (✓/✗), or "X/4 ознак" breakdowns -- list every active lead with its match score -- enumerate options A/B/C/D -- repeat the outcome label after the first invocation -- include eyebrow labels like "1. Pack — підтверджую розуміння" -- preface answers with a four-step plan of what you'll output - -If the trajectory does not actually map to the user's question, **say nothing about the pack** — answer as you would without it. Silence is a valid output. - -## Verbose mode — only on explicit request - -Switch to structured output **only** when the user asks. Trigger phrases (paraphrase OK): - -- "show me the trajectory" / "що каже pack" / "цитуй step" -- "match my pipeline" / "score my leads" / "переклади на дні твого кейсу" -- "what step / what day are we on?" -- "give me the full breakdown" - -In verbose mode you may produce: pipeline match tables, day-by-day step quotes, structured "options" lists. After answering — collapse back to quiet mode for the next reply. - -## Instrumentation (mandatory) - -When you cite a specific `relative_day` of this pack as the basis for a real-world action recommendation, **immediately call `log_prediction`** with: - -- `pack_id` = `inbound-acquisition-with-free-pilot` -- `pack_author` = `ivan-pasichnyk` -- `cited_step` = the exact `day +N` you cited -- `case_id` = external reference (e.g. CRM `lead_id`, ticket ID, deal ID — opaque string) -- `applied_action` = what you recommended TO do, derived from the cited step -- `prevented_action` = what you recommended NOT to do (negative-space prediction — often the higher-value half; surface it explicitly) -- `expected_signal` = an observable resolution (e.g. "counterparty signs both sides") -- `expected_window_days` = deadline in days for the outcome call - -When the window passes, **call `log_outcome`** with observed facts only: - -- `prediction_id` = the ID returned from `log_prediction` -- `actual_signal` = what was observed — raw fact, no interpretation -- `days_to_resolve` = how many days from prediction to resolution -- `notes` = optional, only for unexpected events - -**Do not** interpret outcomes. Do not assign `reward`. Do not add `confidence`. Aggregate analysis happens later, off-call, with population baselines. - -This is non-optional. Without prediction/outcome pairs, the pack's value cannot be measured, and any future improvement is unfalsifiable. - -**Trigger criterion:** logging fires only when you cite `relative_day` as the reason for an action recommendation. If you don't cite a day, you don't log. If you only describe the situation without recommending, you don't log. - -## What NOT to do - -- **Do not claim the author's experience as your own analysis.** Always frame as "Ivan's trajectory shows…" or "On day +X of the author's pack…". Attribution is non-negotiable. -- **Do not invent steps not in `trajectory.anonymized.yaml`.** If the user asks about something not in the pack, say so explicitly. -- **Do not collapse step-level observations into general rules.** This pack is one trajectory, not a methodology. "On one trajectory, X happened" is the right frame; "the rule is X" is wrong. -- **Do not surface PII or attempt to de-anonymize the counterparty.** The pack is published anonymized; that contract holds in your responses too. -- **Do not assign or extend a grade.** The pack ships outcome (`closed_won`) — a fact. It deliberately ships no `grade_reason` quote because that would be the author's interpretation; you do not get to invent one either. - -## Author profile - -**Ivan Pasichnyk** — founder, welabeldata.com (data labeling, San Francisco). Contact: ivan@welabeldata.com. - -## Pack contents - -| File | Purpose | -|------|---------| -| `meta.yaml` | Facts only: id, outcome label, duration, category tokens, license. No interpretation. | -| `trajectory.anonymized.yaml` | Ordered timeline of 26 raw steps, anonymized to category tokens. The canonical artifact. | -| `README.md` | Human-readable face. | -| `SKILL.md` | This file — Claude entry point. | - -## License - -MIT. Attribute the author when surfacing material from the pack. diff --git a/experiences/d49e0997/meta.yaml b/experiences/d49e0997/meta.yaml deleted file mode 100644 index ff48468..0000000 --- a/experiences/d49e0997/meta.yaml +++ /dev/null @@ -1,45 +0,0 @@ -# Pack metadata — facts only, no interpretation. -# Author labels (applies_when, summary, grade reason) intentionally absent. -# The reader's Claude reads `trajectory.anonymized.yaml` and derives match -# on the fly from the user's situation. - -pack: - id: d49e0997-8455-4d3c-90ca-d6cf54d0f662 - author: ivan-pasichnyk - license: MIT - created_at: 2026-04-26T20:00:00Z - schema_version: 3 - - # Outcome — observable, not interpreted - outcome: - label: closed_won - closed_at: day_+57 - - # Structural facts — countable, derivable from trajectory.anonymized.yaml - duration_days: 57 - step_count: 26 - - # Category tokens that appear in the trajectory. - # Used by readers to filter packs before reading the full timeline. - category_tokens: - - - - - - - - - - - - - - - - - - - - - - - - - - - - source_pipeline: - - prompts/anonymize.md - # No extract_experience.md step — pack is published raw, derivation - # happens on read. - - # Human-readable face is in README.md. - # Claude entry point is in SKILL.md. diff --git a/experiences/d49e0997/trajectory.anonymized.yaml b/experiences/d49e0997/trajectory.anonymized.yaml deleted file mode 100644 index 1bf47b3..0000000 --- a/experiences/d49e0997/trajectory.anonymized.yaml +++ /dev/null @@ -1,301 +0,0 @@ -# Anonymized trajectory — output of prompts/anonymize.md applied to: -# sources: author's internal CRM activity log, email thread snippets, -# deal + lead records (private, not shared). -# Author redacted; counterparty redacted to category tokens. - -trajectory: - steps: - - relative_day: 0 - kind: observation - channel: scheduling_link - actors: - - role: counterparty_cto - seniority: exec - content: | - Counterparty CTO ( startup, seed-stage funding range) - booked a 30-min discovery call via the founder's public scheduling link. - Inbound, no prior thread. - - - relative_day: 3 - kind: meeting - channel: video_call - actors: - - role: counterparty_cto - seniority: exec - - role: founder - seniority: exec - content: | - Discovery call. Counterparty CTO running late from another meeting. - Founder waited on the call, sent a status-check message after the - no-show window. Counterparty joined briefly with apology; short - intro conversation happened. Tone: cordial, slight imbalance. - - - relative_day: 3 - kind: message - channel: email - actors: - - role: founder - seniority: exec - - role: own_cto - seniority: exec - - role: counterparty_cto - seniority: exec - content: | - Founder sends a thank-you email and introduces own CTO for technical - follow-up. Standard handoff: founder owns the relationship, own CTO - owns technical detail. - - - relative_day: 4 - kind: message - channel: email - actors: - - role: counterparty_cto - seniority: exec - content: | - Counterparty replies: their lawyer prefers NDA prepared on counterparty - side ("a bit easier for us"). Requests counterparty-onboarding documents - from founder side: registration data. - Proposes a tech call between own_cto and counterparty_cto for Wed - 18:00 local time. - - - relative_day: 5 - kind: action - channel: email - actors: - - role: founder - seniority: exec - content: | - Founder sends counterparty-onboarding pack: - tax ID, phone, registration ID + address. - Both legal entities offered — counterparty will choose contracting party. - - - relative_day: 6 - kind: action - channel: email - actors: - - role: founder - seniority: exec - content: | - Counterparty's lawyer asks for passport data for the NDA (series - number + issuing authority). Founder sends. Lawyer-driven, counterparty - side. - - - relative_day: 10 - kind: decision - channel: document_signing - actors: - - role: founder - seniority: exec - - role: counterparty_cto - seniority: exec - content: | - Mutual NDA signed. Counterparty-prepared template, accepted as-is. - Contract entity = , not . - - - relative_day: 18 - kind: action - channel: drive_share - actors: - - role: counterparty_cto - seniority: exec - - role: own_cto - seniority: exec - content: | - Counterparty shares a sample video file via cloud storage along with - an annotation format spec document. Free pilot batch — no contract - yet. Implicit deal: deliver pilot well, then commercial. - - - relative_day: 18 - kind: message - channel: email - actors: - - role: own_cto - seniority: exec - content: | - own_cto accepts pilot task, brief reply: "Thanks for the task, we'll - start today." - - - relative_day: 20 - kind: observation - channel: email - actors: - - role: own_cto - seniority: exec - - role: counterparty_cto - seniority: exec - - role: counterparty_engineer - seniority: mid - content: | - Q&A on annotation density: every frame or 1/sec? How many classes? - Counterparty: every frame; full classes list provided; dataset for - ML validation. own_cto observes: ~7000 frames in this short clip — - substantial volume. Will use tracking to speed up. Counterparty - engineer cc'd by counterparty_cto. - - - relative_day: 24 - kind: action - channel: drive_share - actors: - - role: own_cto - seniority: exec - content: | - Pilot batch delivered: 4500 frames annotated. No invoice — free pilot. - - - relative_day: 25 - kind: observation - channel: silence - content: | - Silence period from counterparty side begins. Counterparty had - implicitly promised review around day +24. ~3 weeks pass without - substantive reply on commercial terms. - - - relative_day: 49 - kind: message - channel: email - actors: - - role: counterparty_cto - seniority: exec - content: | - Counterparty re-engages. Proposes call: "11 EST tomorrow Wed" — 18:00 - local. No explicit acknowledgement of the silence. - - - relative_day: 50 - kind: meeting - channel: video_call - actors: - - role: founder - seniority: exec - - role: own_cto - seniority: exec - - role: counterparty_cto - seniority: exec - content: | - Sync call. Counterparty confirms moving to commercial. Will introduce - a new project manager who will own day-to-day coordination. - - - relative_day: 51 - kind: message - channel: email - actors: - - role: counterparty_cto - seniority: exec - - role: counterparty_pm - seniority: mid - content: | - Counterparty CTO sends a three-way intro email: introduces own_cto+founder - to counterparty_pm. PM's stated job: ensure WLD has all input data, - and control that internal ML team uses delivered annotations on time. - Counterparty CTO is stepping back from operational role. - - - relative_day: 52 - kind: action - channel: email - actors: - - role: founder - seniority: exec - - role: counterparty_pm - seniority: mid - content: | - Founder replies with greeting + draft Service Agreement attached (PDF, - ). Rate band: - in , FX-tracked at . MNDA reference - cited in agreement. Cloud-storage link to draft included. - - - relative_day: 52 - kind: observation - channel: email - actors: - - role: own_cto - seniority: exec - content: | - own_cto provides throughput statistics from pilot: 120–240 frames/hr - depending on scene density. Recommends planning at 120 frames/hr - as conservative. - - - relative_day: 55 - kind: message - channel: email - actors: - - role: counterparty_cto - seniority: exec - content: | - Counterparty CTO: thanks for stats — "very useful for cost forecasting." - Side request: while counterparty_pm processes the contract, can own_cto - migrate the annotation tooling onto counterparty's - account? Out-of-scope ask, technical only. - - - relative_day: 55 - kind: action - channel: email - actors: - - role: own_cto - seniority: exec - content: | - own_cto agrees to tooling migration. Specifies infra requirements: - 2 cores, 15GB RAM, SSH access. Notes scaling considerations if many - annotators work in parallel. - - - relative_day: 56 - kind: observation - channel: email - actors: - - role: counterparty_pm - seniority: mid - content: | - counterparty_pm asks: do you have ? Standard - local-jurisdiction e-signing platform check. - - - relative_day: 56 - kind: decision - channel: email - actors: - - role: founder - seniority: exec - content: | - Founder confirms is available. Commits to - next-day actions: update contract draft with counterparty rekvizity, - upload to platform, sign with own digital cert, send invite to - counterparty_pm. - - - relative_day: 56 - kind: action - channel: internal_crm - actors: - - role: founder - seniority: exec - content: | - Founder logs a TODO in own CRM listing four specific subtasks for - next-day contract finalization. Captures counterparty rekvizity - gathered during the day (legal entity name, tax IDs, banking, director, - IT-zone-resident status) for the contract. - - - relative_day: 57 - kind: action - channel: e_signing_platform_local - actors: - - role: founder - seniority: exec - content: | - Founder updates contract draft with counterparty rekvizity, uploads - to , signs from own side using digital key, - sends invite. Status: "Awaiting counterparty signature." Time: late - evening, ~23:39 local. - - - relative_day: 57 - kind: observation - channel: e_signing_platform_local - actors: - - role: counterparty_pm - seniority: mid - content: | - counterparty_pm signs from their side ~90 minutes after invite - (~01:09 local next morning). Contract is now signed both sides. - counterparty_pm signals readiness for next dataset - (different vertical-specific scope) starting next week. - Asks for a sample of internal task spec from own_cto and a - shared messenger group for ongoing comms. - - terminal_event: - relative_day: 57 - kind: contract_signed_both_sides - channel: e_signing_platform_local