@tangle-network/starter-foundry 0.7.2 → 0.13.0

package/registry/families/agent-runtime-business-partner-ts/files/README.md

@@ -0,0 +1,94 @@
+# business-partner
+
+Executive thinking-partner agent bundle. **Advisory only — not a board
+member, not a fiduciary, not a substitute for the operator's lawyer,
+CPA, or HR counsel.** Runs a weekly review cadence, designs OKRs, and
+maintains a decision journal. Citation-grounded for any market or
+strategy claim via the research-corpus layer.
+
+## What this bundle is
+
+An agent's filesystem: a system prompt + weekly-review / OKR /
+decision-journal templates + Cloudflare Worker shell + Tangle Sandbox
+SDK + the research-corpus tool kit (arxiv / Semantic Scholar /
+OpenAlex / Crossref). Runs in a per-operator Tangle sandbox; LLM calls
+go through `router.tangle.tools`.
+
+## Advisory boundary
+
+This bundle is **moderate stakes**. The biggest failure mode is
+over-reliance: the operator treats a thinking partner as a decision
+authority. The system prompt enforces an escalation contract for every
+class of question that requires a real professional:
+
+- HR / personnel actions → employment counsel
+- M&A specifics → M&A counsel + banker
+- Securities offerings → corporate counsel
+- Comp negotiations beyond a public rubric → HR + employment counsel
+- Legal advice → lawyer
+- Fiduciary / board-duty territory → board chair + corporate counsel
+
+Every escalation emits a `:::escalation` block naming the professional
+and the question to bring them. Preparation for that conversation
+(framing, documents, asks) is on-scope; the opinion itself is not.
+
+## Weekly cadence pattern
+
+The bundle ships a Monday-morning cron (`0 14 * * 1` = 14:00 UTC ≈
+07:00 PT / 10:00 ET) that prompts the operator to start a weekly
+review. The review walks seven dimensions — revenue / pipeline / team
+/ product / runway / customer-feedback / personal-energy — and
+produces an `:::artifact` block the operator can review, edit, and
+file. See `templates/weekly-review-protocol.md` for the full method.
+
+The cadence is intentional. The agent holds it even when the operator
+wants to skip — skipping the cadence is a leading indicator the
+operator is reactive rather than proactive, which is itself a signal
+worth surfacing.
+
+## Research-corpus integration
+
+When the operator asks for market context, competitive landscape, or
+benchmark data, the agent uses the research-corpus tools to pull from
+arxiv / Semantic Scholar / OpenAlex / Crossref and emits a `:::survey`
+block with inline `[surname, year]` citations. **Hallucinated market
+data is the failure mode this layer prevents.** If no citation exists,
+the agent downgrades the claim to a hypothesis the operator can test.
+
+## Domain capabilities
+
+- `weekly-review-protocol` — the seven-dimension Monday review.
+  Methodology in `templates/weekly-review-protocol.md`.
+- `okr-design` — Doerr-style OKRs (3–5 objectives × 3 KRs);
+  aspirational vs committed split; mid-quarter 0/0.3/0.7/1.0 grading.
+  Methodology in `templates/okr-design.md`.
+- `decision-journal` — Bezos Type 1 / Type 2 reversibility; predicted
+  outcome with timeframe; what would change my mind; honest scoring at
+  the agreed checkpoint. Methodology in `templates/decision-journal.md`.
+
+## Extension points
+
+- `system-prompt.md` — adjust role / advisory boundary / escalation
+  triggers. Re-run `prompt-frontmatter-valid` after edits.
+- `templates/weekly-review-protocol.md` — change the seven dimensions
+  for non-startup contexts (e.g. drop "runway" for a profitable
+  business).
+- `templates/okr-design.md` — swap to a different goal-setting frame
+  (V2MOM, Hoshin Kanri, NCT) by replacing the file; keep the
+  capability id stable.
+- `defaults.allowedDomains` — additional outbound URLs (e.g.
+  Crunchbase, PitchBook) the bundle is permitted to reach. Anything
+  outside this list is sandbox-blocked.
+
+## Source material
+
+Templates draw on:
+
+- Andy Grove, *High Output Management* (operating cadence, output
+  measurement)
+- John Doerr, *Measure What Matters* (OKR shape, grading scale,
+  aspirational vs committed split)
+- Jeff Bezos, 1997 + 2015 + 2016 shareholder letters (Type 1 vs
+  Type 2 decisions, disagree-and-commit, day-1 mentality)
+- Shane Parrish / Farnam Street (decision journal format, predictive
+  scoring, what-would-change-my-mind discipline)

package/registry/families/agent-runtime-business-partner-ts/files/TOOLS.md

@@ -0,0 +1,32 @@
+# TOOLS — agent-runtime-business-partner-ts
+
+The bundle inherits all primitives from `agent-base:secure`: `secrets`, `workspace`, `webhook-in`, `webhook-out`, `schedule`, `identity`, `audit`. Plus generic agent tools: `Read`, `Write`, `Edit`, `Glob`, `Grep`, `Bash`, `WebFetch`.
+
+This file lists **domain-specific tools the operator MAY add** if the deployment needs them. Each entry is intent — not implementation. The agent itself can build any of these on demand using `Bash`/`Write` if the operator hasn't.
+
+## Research corpus (inherited from `agent-tools:research-corpus`)
+
+| Capability | Intent |
+|---|---|
+| `corpus.arxiv(query)` | arXiv paper search |
+| `corpus.semanticScholar(query)` | Semantic Scholar |
+| `corpus.openalex(query)` | OpenAlex |
+| `corpus.crossref(query)` | Crossref DOI metadata |
+
+## Domain tools the operator may want
+
+Stub list — replace with role-specific entries. Keep ≤10 domain tools per deployment; more is fragmentation. Each tool should be:
+- Single-purpose
+- JSON output
+- ≤100 LOC
+- Listed here when added
+
+| Tool | Intent | Notes |
+|---|---|---|
+| `weekly-review-protocol` | Concrete tool implementing the `weekly-review-protocol` capability | Operator implements when needed |
+| `okr-design` | Concrete tool implementing the `okr-design` capability | Operator implements when needed |
+| `decision-journal` | Concrete tool implementing the `decision-journal` capability | Operator implements when needed |
+
+## Build a new tool when you need it
+
+The agent's job includes building tools when the measurement doesn't exist. New tools should be small, JSON-output, single-purpose. Add an entry here via PR after shipping.

package/registry/families/agent-runtime-business-partner-ts/files/agent.json

@@ -0,0 +1,40 @@
+{
+  "name": "business-partner",
+  "description": "Executive thinking-partner agent bundle — co-founder / executive coach. Runs a weekly review cadence, designs OKRs, and maintains a decision journal. Composes the agent-runtime substrate with the research-corpus layer (arxiv / Semantic Scholar / OpenAlex / Crossref) so any market or strategy claim is citation-grounded rather than hallucinated. Advisory only — never replaces the operator's lawyer, CPA, or board.",
+  "version": "0.1.0",
+  "tags": [
+    "agent-runtime",
+    "executive-coaching",
+    "advisory",
+    "weekly-review",
+    "okrs",
+    "decision-journal",
+    "cloudflare-worker"
+  ],
+  "prompt": {
+    "systemPromptFile": "AGENTS.md"
+  },
+  "tools": {
+    "filesystem": true,
+    "shell": true,
+    "router": true
+  },
+  "permissions": {
+    "filesystem.write": "ask",
+    "shell.exec": "ask",
+    "network": "ask"
+  },
+  "resources": {
+    "files": [
+      {
+        "source": "methodology/"
+      },
+      {
+        "source": "README.md"
+      },
+      {
+        "source": "TOOLS.md"
+      }
+    ]
+  }
+}

package/registry/families/agent-runtime-business-partner-ts/files/methodology/decision-journal.md

@@ -0,0 +1,149 @@
+---
+capability: decision-journal
+status: active
+source: hand-authored
+retrieved: 2026-04-25
+---
+
+# Decision Journal
+
+A decision-journal entry produces a `:::artifact` block tagged
+`template: decision-journal` capturing a decision before it is made,
+with a predicted outcome, a checkpoint date, and an honest score
+written **after** the checkpoint comparing the prediction to reality.
+
+The point is not to make better decisions today; the point is to
+**calibrate** the operator over time by forcing them to commit
+predictions to paper before reality renders verdict. A decision
+journal that is never reviewed is a journal, not a decision journal.
+
+## When to use
+
+- Any decision the operator labels "important" or "I keep going back
+  and forth on."
+- Any **Type 1 decision** (irreversible — see below).
+- Any decision that, if wrong, would cost > 1 month of team capacity
+  to undo.
+- When the operator says "I need to think about this", "I'm stuck on
+  this call", "should I do X".
+
+## Method
+
+### 1. Name the decision
+
+A single sentence. "Should we hire a VP Sales now or wait two
+quarters?" Not "thinking about sales leadership."
+
+If the operator cannot state it in one sentence, the decision isn't
+ripe — help them frame it before journaling.
+
+### 2. Reversibility (Type 1 vs Type 2 — Bezos)
+
+- **Type 1** — one-way door. Hard or impossible to reverse. Treat
+  with deliberation, gather more evidence, slow down. Examples:
+  selling the company, firing a co-founder, taking a strategic
+  investor with veto rights.
+- **Type 2** — two-way door. Cheap to reverse if wrong. Move fast,
+  bias to action, treat the cost of delay as real. Examples: most
+  hires, most product bets, most pricing experiments.
+
+Most decisions are Type 2 and the operator over-deliberates them.
+Most "I'm stuck" moments are Type 2 dressed up as Type 1. Naming the
+class explicitly is half the value.
+
+### 3. Current state of evidence
+
+Three to five bullets, each citing the source of the claim:
+
+- Customer signal (which customers, what they said, when)
+- Market signal (citation via research-corpus if a published claim;
+  internal data if proprietary)
+- Team signal (who has weighed in, what was their stake)
+- Financial signal (what the model says under what assumptions)
+
+If a bullet has no citation and no source, mark it **opinion** so
+the operator can see how much of their decision rests on intuition
+vs. evidence.
+
+### 4. Alternatives considered
+
+At least two, ideally three. The "do nothing" option is always one
+of them. If the operator cannot name a real alternative, they have
+not stress-tested the decision.
+
+For each alternative, one sentence on why it was rejected.
+
+### 5. Predicted outcome (with timeframe)
+
+A specific, falsifiable prediction. Not "this will go well" — that
+cannot be scored.
+
+- Concrete number ("ARR will be $X by end of Q4")
+- Concrete event ("we will close the round by August 1")
+- Concrete observation ("by month 3, the new hire will have closed
+  3 enterprise deals")
+
+The prediction must be reviewable by an outsider without asking the
+operator what they meant.
+
+### 6. What would change my mind
+
+Two to three signals that, if observed, would cause the operator to
+reverse the decision. This is the **kill criteria** — write it
+before reality starts to flatter or punish the decision, because
+afterward the operator will rationalize.
+
+Examples: "If we're below 10 customers by month 6, we kill the
+self-serve motion." "If the new hire's first 30-day plan slips by
+two weeks, we end the trial."
+
+### 7. Review at agreed checkpoint
+
+Set a date. Add it to the operator's calendar in the same artifact.
+
+At checkpoint:
+
+- **Was the prediction correct?** (yes / partly / no — name the gap)
+- **Why?** — was the model right and the world cooperated, or was
+  the model wrong and the world cooperated anyway? Distinguishing
+  good outcome from good decision is the calibration the journal
+  exists to provide.
+- **What would I do differently next time?** — one sentence.
+
+### 8. Honest scoring
+
+Score the decision on a 1–5 scale on each axis:
+
+- **Process** — was the right method used given Type 1 / Type 2?
+- **Information** — did the operator gather what was reasonably
+  available?
+- **Outcome** — did reality match the prediction?
+
+A high outcome score with a low process score is a warning, not a
+victory: the operator got lucky and is at risk of over-trusting the
+method.
+
+## Output shape
+
+Wrap the entry in a `:::artifact` block tagged
+`template: decision-journal`, dated, with the eight numbered sections
+above. After checkpoint review, append the scoring section to the
+**same** artifact — do not start a new entry; the predict-then-score
+pairing is the load-bearing part.
+
+## Escalation
+
+If the decision involves any of the system-prompt's mandatory
+escalation triggers (HR, M&A, securities, comp, legal, fiduciary),
+emit a `:::escalation` block **before** opening the journal entry.
+The journal helps the operator think; it does not substitute for the
+professional opinion the trigger requires.
+
+## Source
+
+Jeff Bezos, 1997 + 2015 + 2016 shareholder letters (Type 1 vs Type 2,
+disagree-and-commit). Shane Parrish / Farnam Street decision-journal
+template (kill criteria, post-hoc scoring, calibration discipline).
+Daniel Kahneman, *Thinking, Fast and Slow* (separating outcome
+quality from decision quality). Adapted with concrete checkpoint and
+scoring scaffolding for an operator-cadence context.

package/registry/families/agent-runtime-business-partner-ts/files/methodology/index.json

@@ -0,0 +1,25 @@
+{
+  "entries": [
+    {
+      "id": "weekly-review-protocol",
+      "capability": "weekly-review-protocol",
+      "path": "./weekly-review-protocol.md",
+      "tags": ["cadence", "weekly", "operating-rhythm"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "okr-design",
+      "capability": "okr-design",
+      "path": "./okr-design.md",
+      "tags": ["goal-setting", "okrs", "quarterly"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "decision-journal",
+      "capability": "decision-journal",
+      "path": "./decision-journal.md",
+      "tags": ["decision-making", "reversibility", "post-hoc-scoring"],
+      "version": "0.1.0"
+    }
+  ]
+}

package/registry/families/agent-runtime-business-partner-ts/files/methodology/okr-design.md

@@ -0,0 +1,130 @@
+---
+capability: okr-design
+status: active
+source: hand-authored
+retrieved: 2026-04-25
+---
+
+# OKR Design
+
+An OKR design session produces a `:::artifact` block tagged
+`template: okr-design` containing 3–5 objectives, each with 3 key
+results, classified as **aspirational** or **committed**, with a
+mid-quarter check rubric and explicit cascading from company → team →
+individual.
+
+OKRs are a **focusing tool**, not a tracking tool. The output is a
+short list the operator can recite from memory; if it cannot be
+recited, it is too long.
+
+## When to use
+
+- Quarter boundary (week before quarter starts, or first week if
+  carrying forward).
+- After a strategy shift (fundraise, pivot, major hire) that
+  invalidates the current set.
+- When the operator says "let's set OKRs", "what should our goals
+  be", "how do I measure progress on X".
+
+## Method
+
+### 1. Pick 3–5 objectives
+
+Each objective is a **qualitative, time-bound, inspirational
+statement**. It says where the team is going, not how to measure it.
+
+- Good: "Make Tangle the default agent runtime for sandboxed AI."
+- Bad: "Hit $1M ARR." (that's a KR, not an objective)
+- Bad: "Improve marketing." (no direction, no time-bind)
+
+Limit: 3–5. More than 5 means nothing is the priority. Less than 3
+usually means the operator is collapsing distinct surfaces.
+
+### 2. For each objective, write 3 key results
+
+Every KR must satisfy three properties:
+
+1. **Observable** — at the end of the quarter, an outsider can
+   determine whether the KR was hit, without asking the operator.
+2. **Time-bound** — has a date. "By end of Q3" is the floor.
+3. **Numeric or binary** — has a number ($X ARR, N customers, P95
+   latency < 300ms) or a binary outcome (shipped / not shipped, with
+   a clear definition of shipped).
+
+KRs that fail any of the three are not KRs — they are tasks or
+intentions. Reject them.
+
+### 3. Classify each objective: aspirational vs committed
+
+- **Committed** — the team is on the hook for hitting these. Missing
+  is a serious problem. Grade them at 0.7+ to call them shipped.
+- **Aspirational** — the team is reaching. Hitting 0.7 is a strong
+  outcome; hitting 1.0 is exceptional. These should feel
+  uncomfortable when written.
+
+A typical split is 70% committed, 30% aspirational. Pure committed
+means the team is sandbagging; pure aspirational means the team has
+no operational floor.
+
+### 4. Cascade
+
+Company OKRs → team OKRs → individual OKRs. Each level's objectives
+must trace to a parent KR or objective at the level above. If a team
+OKR has no company-level parent, either the team is doing
+unauthorized work or the company OKRs are missing a surface.
+
+Cascading is **not** decomposing — a team's KRs are not just slices
+of the company KRs. The team's KRs answer "what does my team need to
+deliver such that the company KR can be hit?"
+
+### 5. Mid-quarter check (week 6)
+
+Grade each KR on the Doerr scale:
+
+- **0.0** — no progress, abandoned, or invalidated.
+- **0.3** — making progress but unlikely to hit by quarter-end.
+- **0.7** — strong progress; on track to hit; shipped if committed.
+- **1.0** — exceeded; rare; reserved for genuine over-delivery.
+
+Mid-quarter is the window to **kill or escalate**, not to spin. A KR
+graded 0.0 or 0.3 at week 6 either gets a credible recovery plan or
+gets cut from the OKR set entirely. Carrying dead KRs to quarter-end
+trains the team that OKRs are theater.
+
+## Common antipatterns (refuse these)
+
+- **Sandbagged KRs** — numbers the team will hit by doing nothing
+  different. Push back: "What would 0.7 look like if we actually
+  reached?"
+- **KPI-as-KR** — using a steady-state metric (uptime, NPS) as a KR
+  when the team doesn't intend to change it. KPIs are dashboards;
+  KRs require deliberate action.
+- **OKR-as-task-list** — three KRs that are all "ship feature X."
+  Tasks are how; KRs are what changed for the customer / business.
+- **Too many** — 8 objectives, 30 KRs. The team will track the easy
+  ones and quietly drop the rest. Force a cut.
+- **No number** — "Improve developer experience." Reject. Replace
+  with a measurable proxy (P50 time-to-first-deploy, NPS from
+  internal devs, etc.).
+
+## Output shape
+
+Wrap the entire OKR set in a `:::artifact` block tagged
+`template: okr-design`, dated, with quarter named, objectives
+numbered, KRs lettered, aspirational vs committed flagged on each
+objective.
+
+## Escalation
+
+If the operator asks the agent to **set** the OKRs (rather than
+help design them), escalate. The operator owns the goals; the agent
+sharpens them. Setting goals for the operator is the failure mode
+this whole template prevents.
+
+## Source
+
+John Doerr, *Measure What Matters* (canonical OKR shape, grading
+scale, aspirational vs committed split, cascading discipline). Andy
+Grove, *High Output Management* (the original objectives + key
+results frame at Intel). Adapted with antipattern list drawn from
+public OKR retrospectives at Google, LinkedIn, and Intuit.

package/registry/families/agent-runtime-business-partner-ts/files/methodology/weekly-review-protocol.md

@@ -0,0 +1,103 @@
+---
+capability: weekly-review-protocol
+status: active
+source: hand-authored
+retrieved: 2026-04-25
+---
+
+# Weekly Review Protocol
+
+A weekly review produces a `:::artifact` block tagged
+`template: weekly-review-protocol` capturing the operator's state
+across seven dimensions, what changed, what surprised, what's
+blocking, the one bet for next week, and the one thing to stop.
+
+The cadence is the point. A review skipped is a leading indicator the
+operator is reactive rather than proactive — surface that signal
+explicitly when it happens.
+
+## When to use
+
+- Triggered by the Monday-morning cron (`0 14 * * 1`).
+- Triggered manually when the operator says "weekly review",
+  "let's do the review", "what's my state".
+- After a board meeting, fundraise close, or major personnel change —
+  run the review even if it's mid-week, then resume the Monday rhythm.
+
+## The seven dimensions
+
+For each dimension, capture: **current number / state**, **delta vs
+last week**, **one-sentence interpretation**.
+
+1. **Revenue** — MRR / ARR / cash collected. Delta vs last week and vs
+   plan. Flag if delta < 0 or < plan by > 10%.
+2. **Pipeline** — qualified opportunities, weighted pipeline, top 3
+   deals by stage. Flag stalled deals (no movement > 14 days).
+3. **Team** — headcount, open roles, anyone in 1:1 distress, anyone
+   exceptional this week. Flag any retention risk.
+4. **Product** — shipped this week, in flight, blocked. Flag any
+   reliability incident, regression, or customer-visible bug.
+5. **Runway** — months of cash at current burn; trailing 3-month
+   average burn; date the runway alarm fires (T-9 months from zero).
+   Flag if runway shortened > 1 month vs last review.
+6. **Customer feedback** — top three signals from sales calls, support
+   tickets, NPS / churn surveys this week. Flag any pattern repeating
+   3+ times.
+7. **Personal energy** — operator's own state on a 1–10 scale, with
+   one sentence on why. Flag if < 5 for two consecutive weeks — that
+   is itself a leading indicator of decisions made under fatigue.
+
+## Five questions after the dimensions
+
+After the seven-dimension scan, walk the operator through:
+
+- **What changed since last week?** — name the deltas explicitly, not
+  in aggregate. "Revenue +$12k, lost the Acme deal, hired Sarah."
+- **What's surprising?** — anything that violated last week's mental
+  model. Surprise is information; do not let it pass without a
+  decision-journal entry if the surprise is large enough to change
+  strategy.
+- **What's blocking?** — name the constraint, not the symptom. "Hiring
+  is slow" is a symptom; "I don't have a referral pipeline and I
+  haven't written the JD" is a constraint.
+- **One bet for next week** — the single most leveraged action the
+  operator will take. Force a single bet; if the operator names
+  three, ask which one would still ship if the other two failed.
+- **One thing to stop** — what activity, meeting, or commitment the
+  operator will drop to make room for the bet. A bet without a stop
+  is wishful thinking; weekly capacity is fixed.
+
+## Output shape
+
+Wrap the entire review in a `:::artifact` block, tagged
+`template: weekly-review-protocol`, dated, with the seven-dimension
+table at the top and the five-question narrative below.
+
+## Escalation
+
+If the dimension scan surfaces:
+
+- Runway < 9 months → escalate to fundraise-prep conversation +
+  recommend the operator re-confirm runway with their CPA.
+- A personnel-action signal (termination, performance-management,
+  harassment) → emit a `:::escalation` block immediately and refer to
+  HR / employment counsel.
+- A customer-feedback pattern that suggests product-market-fit
+  regression → flag for a decision-journal entry, do not let it
+  default into "we'll watch it."
+
+## Honesty discipline
+
+Do not let the operator round up. If revenue is below plan, name it.
+If a key person is at retention risk, name them. If runway shortened,
+say so. Soft-pedaling the review is the most expensive thing the
+operator can do — the review only earns its hour if it surfaces what
+the operator was avoiding.
+
+## Source
+
+Andy Grove, *High Output Management*, ch. 4 (operating cadence) and
+ch. 7 (output-oriented review). Bezos shareholder letters (day-1
+mentality, "what would change my mind"). Adapted for an early-stage
+founder context where runway and personal energy are first-class
+dimensions.