@tangle-network/starter-foundry 0.7.3 → 0.13.2

package/registry/families/agent-runtime-research/files/README.md

@@ -0,0 +1,45 @@
+# research-assistant
+
+Greenfield agent-runtime bundle. Demonstrates the SF `agent-runtime`
+surface end-to-end: a system prompt + domain templates + Cloudflare
+Worker triggers, with no source product to extract from.
+
+## What this bundle is
+
+This bundle is a **filesystem the agent reads at runtime** — a system
+prompt that loads templates conditionally, a Worker shell that exposes
+chat + cron, and a structured-output contract.
+
+There is no `pnpm build` step for the bundle as content. The Worker
+shell builds with `wrangler deploy`; the bundle's actual *artifact* is
+`system-prompt.md` + `templates/` + `wrangler.toml`.
+
+## How a sandbox spawns it
+
+1. Sandbox mounts the bundle directory at `/agent`.
+2. Agent reads `system-prompt.md` first; the YAML frontmatter declares
+   `allowedDomains` + `allowedEnv` for the sandbox to enforce.
+3. On request, agent inspects `templates/index.json`, picks the entry
+   matching the requested capability, and reads that template into
+   context before generating.
+4. Output is wrapped in `:::proposal` / `:::survey` / `:::artifact`
+   blocks the host UI parses.
+
+## Domain capabilities
+
+- `literature-survey` — surveys prior work on a question, ≥3 cited
+  sources, axis-by-axis synthesis. Methodology in
+  `templates/literature-survey.md`.
+- `proposal-drafting` — drafts a 5-section research proposal. First-
+  draft discipline enforced by `templates/proposal-drafting.md`.
+
+## Extension Points
+
+- `system-prompt.md` — change the role, output blocks, or refusal
+  rules. Re-run `prompt-frontmatter-valid` after edit.
+- `templates/index.json` — add new capability rows. Each new row must
+  point at a real `templates/*.md` file or `template-index-valid` will
+  fail.
+- `templates/*.md` — add new domain templates. Each must be ≥40 lines
+  of substance OR include `status: stub` frontmatter (which fails the
+  substance gate honestly).

package/registry/families/agent-runtime-research/files/TOOLS.md

@@ -0,0 +1,22 @@
+# TOOLS — agent-runtime-research
+
+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.
+
+## 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 |
+|---|---|---|
+| `literature-survey` | Concrete tool implementing the `literature-survey` capability | Operator implements when needed |
+| `proposal-drafting` | Concrete tool implementing the `proposal-drafting` 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-research/files/agent.json

@@ -0,0 +1,37 @@
+{
+  "name": "research",
+  "description": "Greenfield agent-runtime bundle: research-assistant agent that reads templates from its own filesystem, runs daily cron, and emits structured proposal blocks. Demonstrates the full agent-runtime substrate end-to-end with no external extraction source.",
+  "version": "0.1.0",
+  "tags": [
+    "agent-runtime",
+    "research",
+    "cloudflare-worker",
+    "greenfield"
+  ],
+  "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-research/files/methodology/index.json

@@ -0,0 +1,18 @@
+{
+  "entries": [
+    {
+      "id": "literature-survey",
+      "capability": "literature-survey",
+      "path": "./literature-survey.md",
+      "tags": ["methodology", "citations"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "proposal-drafting",
+      "capability": "proposal-drafting",
+      "path": "./proposal-drafting.md",
+      "tags": ["methodology", "structure"],
+      "version": "0.1.0"
+    }
+  ]
+}

package/registry/families/agent-runtime-research/files/methodology/literature-survey.md

@@ -0,0 +1,59 @@
+---
+capability: literature-survey
+status: active
+source: hand-authored
+retrieved: 2026-04-25
+---
+
+# Literature Survey methodology
+
+A literature survey produces a `:::survey` block containing at least
+three sources, each with year, one-line summary, and a relevance note
+explaining how the source informs the user's question.
+
+## When to use
+
+Trigger this template when the user asks:
+
+- "What's the state of the art in X?"
+- "What has been published recently on Y?"
+- "Who else has worked on Z?"
+- "Find me background reading on W."
+
+If the user is asking for original synthesis (not a survey of prior
+work), use `proposal-drafting.md` instead — surveys feed proposals,
+not the other way around.
+
+## Method
+
+1. Identify the **scope-defining axes** for the question. For most
+   research questions there are 2–4 of these (e.g., "deep learning for
+   protein folding" has axes: architecture-family, dataset,
+   benchmark-task, year). Name them explicitly in the response.
+2. For each axis, pick a representative source — preferring recent
+   (last 24 months), peer-reviewed, and well-cited where possible.
+3. For each source, capture: title, first-author, venue, year, one-line
+   contribution, one-line relevance to the user's question.
+4. After listing sources, write a 2–3 sentence synthesis that names the
+   axis where the field is converging and the axis where it remains
+   open.
+
+## Output shape
+
+Wrap the entire survey in a `:::survey` block. Cite by `[surname, year]`
+inline; collect full citations at the bottom of the block.
+
+## Citation discipline
+
+Every claim of fact ships with a citation. If you cannot cite a claim,
+soften it to a hypothesis or omit it. Refuse to fabricate citations —
+escalate to a human reviewer if the user pushes you to "just make
+something up."
+
+## Scope limits
+
+This template covers literature surveys, not exhaustive systematic
+reviews (PRISMA-style). If the user asks for a systematic review,
+offer a literature survey + a list of the additional inclusion criteria
+a systematic review would require, and ask whether they want to extend
+scope.

package/registry/families/agent-runtime-research/files/methodology/proposal-drafting.md

@@ -0,0 +1,63 @@
+---
+capability: proposal-drafting
+status: active
+source: hand-authored
+retrieved: 2026-04-25
+---
+
+# Proposal Drafting methodology
+
+A draft proposal is a `:::proposal` block with five sub-sections,
+written tersely. It is a *first draft* — the human reviewer expects to
+edit every section.
+
+## When to use
+
+Trigger this template when the user asks:
+
+- "Write me a research proposal on X."
+- "Draft a grant application for Y."
+- "Help me structure an investigation into Z."
+- "Turn this idea into a fundable plan."
+
+If the user is asking for a survey of prior work to inform a proposal,
+use `literature-survey.md` first; surveys feed proposals.
+
+## Sub-section contract
+
+Every `:::proposal` block contains, in this order:
+
+1. **Title** — one line, descriptive, not a marketing pitch.
+2. **Abstract** — 4–6 sentences. State the question, the gap in prior
+   work, the approach, the deliverable, the impact.
+3. **Methods** — bullets, ordered. Each bullet names a concrete step
+   the team can execute. No vague "explore" or "investigate" verbs.
+4. **Budget** — total + breakdown into ≤5 line items (personnel,
+   compute, materials, travel, indirect). Numeric placeholders are
+   acceptable on first draft; flag them with `<replace>`.
+5. **Timeline** — milestones with month-from-start. Include at least
+   one go/no-go checkpoint that would let the team kill the project
+   before the budget runs out if the early data disagrees.
+
+## Discipline rules
+
+- Cite prior work in Methods using inline `[surname, year]`. If the
+  user has provided a survey block in this conversation, reuse those
+  citations rather than inventing new ones.
+- Refuse to inflate impact claims. If you don't have evidence the
+  proposed work will have a 10x impact, don't claim it.
+- The proposal is a first draft, not a finished document. Mark every
+  unverified estimate with `<replace>` so the reviewer cannot miss it.
+
+## Refusal mode
+
+Refuse to draft a proposal whose central claim contradicts known facts
+the user has not addressed. Escalate; propose a "skeptical-priors"
+variant where the proposal proves the contrarian claim experimentally
+rather than asserting it.
+
+## Output shape
+
+Wrap the entire draft in a `:::proposal` block. The five sub-sections
+appear as `### Title`, `### Abstract`, `### Methods`, `### Budget`,
+`### Timeline` headings inside the block.

package/registry/families/agent-runtime-research/manifest.json

@@ -0,0 +1,190 @@
+{
+  "id": "agent-runtime-research",
+  "description": "Greenfield agent-runtime bundle: research-assistant agent that reads templates from its own filesystem, runs daily cron, and emits structured proposal blocks. Demonstrates the full agent-runtime substrate end-to-end with no external extraction source.",
+  "tags": [
+    "agent-runtime",
+    "research",
+    "cloudflare-worker",
+    "greenfield"
+  ],
+  "taxonomy": {
+    "language": "markdown",
+    "runtime": "cloudflare-worker",
+    "surface": "agent-runtime"
+  },
+  "slots": {
+    "agent-base": {
+      "options": [
+        "agent-base:tangle"
+      ],
+      "default": "agent-base:tangle"
+    },
+    "agent-tools": {
+      "options": [
+        "agent-tools:research-corpus",
+        "agent-tools:phony-voice",
+        "agent-tools:clinical-screeners"
+      ],
+      "default": "agent-tools:research-corpus"
+    },
+    "agent-output": {
+      "options": [
+        "agent-output:blocks"
+      ],
+      "default": "agent-output:blocks"
+    }
+  },
+  "defaults": {
+    "projectType": "agent-runtime-research",
+    "agentName": "research-assistant",
+    "publicVars": [
+      "AGENT_NAME"
+    ],
+    "routes": [
+      {
+        "path": "/api/chat",
+        "auth": "bearer",
+        "callsTools": [
+          "search",
+          "summarize"
+        ]
+      },
+      {
+        "path": "/api/health",
+        "auth": "none",
+        "callsTools": []
+      }
+    ],
+    "declaredCapabilities": [
+      "literature-survey",
+      "proposal-drafting"
+    ],
+    "runtime": {
+      "sandbox": "tangle",
+      "noNewPrivileges": true,
+      "capDrop": "ALL"
+    },
+    "schedule": [
+      {
+        "id": "scheduled-1",
+        "cron": "17 7 * * *",
+        "capability": "literature-survey"
+      },
+      {
+        "id": "scheduled-2",
+        "cron": "17 7 * * 1",
+        "capability": "proposal-drafting"
+      }
+    ],
+    "outboundDomains": [
+      "api.tangle.tools"
+    ],
+    "secrets": []
+  },
+  "files": [
+    {
+      "source": "files/agent.json",
+      "target": "agent.json"
+    },
+    {
+      "source": "files/AGENTS.md",
+      "target": "AGENTS.md"
+    },
+    {
+      "source": "files/methodology/index.json",
+      "target": "methodology/index.json"
+    },
+    {
+      "source": "files/methodology/literature-survey.md",
+      "target": "methodology/literature-survey.md"
+    },
+    {
+      "source": "files/methodology/proposal-drafting.md",
+      "target": "methodology/proposal-drafting.md"
+    },
+    {
+      "source": "files/README.md",
+      "target": "README.md"
+    },
+    {
+      "source": "files/TOOLS.md",
+      "target": "TOOLS.md"
+    }
+  ],
+  "validationChecks": [
+    {
+      "type": "file-exists",
+      "path": "AGENTS.md"
+    },
+    {
+      "type": "file-exists",
+      "path": "methodology/index.json"
+    },
+    {
+      "type": "agents-md-valid",
+      "path": "AGENTS.md"
+    },
+    {
+      "type": "methodology-index-valid",
+      "path": "methodology/index.json"
+    },
+    {
+      "type": "schedule-valid",
+      "path": "manifest.json"
+    },
+    {
+      "type": "file-exists",
+      "path": "TOOLS.md"
+    }
+  ],
+  "contextHints": {
+    "commands": [],
+    "entrypoints": [
+      "AGENTS.md"
+    ],
+    "extensionPoints": [
+      "templates/",
+      "skills/"
+    ]
+  },
+  "keywords": [
+    "research",
+    "literature-survey",
+    "proposal",
+    "agent",
+    "sandbox"
+  ],
+  "tieredKeywords": {
+    "tier1": [
+      "research-agent",
+      "literature-survey",
+      "general-research-agent",
+      "general research agent"
+    ],
+    "tier2": [
+      "research",
+      "proposal",
+      "draft"
+    ],
+    "tier3": [
+      "agent"
+    ],
+    "archetypes": [
+      "agent-in-sandbox"
+    ]
+  },
+  "includes": [
+    "agent-base:tangle",
+    "agent-base:secure",
+    "agent-base:memory",
+    "agent-base:scheduler",
+    "agent-base:mcp-registry",
+    "agent-channels:telegram",
+    "agent-channels:discord",
+    "agent-channels:slack",
+    "agent-channels:whatsapp",
+    "agent-channels:imessage",
+    "agent-channels:gmail",
+    "agent-channels:linear"
+  ]
+}

package/registry/families/agent-runtime-sales-engineer-ts/files/AGENTS.md

@@ -0,0 +1,63 @@
+---
+name: sales-engineer
+role: Sales Engineer — technical pre-sales, demo engineering, proof-of-concept design, and competitive technical positioning
+ domain: sales-engineering
+allowedDomains:
+  - api.tangle.tools
+allowedEnv:
+  - TANGLE_API_KEY
+advisoryOnly: true
+escalationRequired: true
+version: 0.1.0
+---
+
+## Role
+
+You are a Sales Engineer — a technical pre-sales professional who works alongside the operator (AE, founder, or sales leader) to **demonstrate technical value**, **design proof-of-concept architectures**, and **position the product against competitive alternatives**. You are **not** a replacement for the operator's actual sales process, legal review, or pricing authority. You do not set pricing, sign contracts, or make commitments on behalf of the company.
+
+State your advisory limit clearly any time the user crosses into territory that requires a real professional — and especially in the first turn of any new conversation.
+
+## Authoritative skills
+
+When the user's request maps to one of these capabilities, load the corresponding template *before* responding. The templates are the methodology source of truth; trust them over training.
+
+- `demo-scripting` → `templates/demo-script.md`
+- `poc-design` → `templates/poc-design.md`
+- `competitive-technical-positioning` → `templates/competitive-technical-positioning.md`
+
+## Output blocks
+
+Wrap structured deliverables in parseable blocks the host UI renders distinctly:
+
+- `:::artifact` — demo scripts, POC designs, competitive positioning briefs, and any other persisted record. Always tag the producing template (e.g. `template: demo-script`).
+- `:::escalation` — emitted whenever a request crosses into territory that requires a real professional (see "Mandatory escalation"). The block names the kind of professional the operator should bring in and the question to bring them.
+- `:::analysis` — short interpretive readouts (e.g. "what this positioning loses you") that aren't the artifact itself but inform the user's next move.
+
+## Mandatory escalation (advisory boundary)
+
+Run the escalation pattern and emit a `:::escalation` block whenever ANY of these fire:
+
+1. **Pricing / discounting** — specific pricing, discount levels, or contract terms. → operator's sales leadership or finance.
+2. **Legal / compliance** — contract language, data privacy commitments, SLA guarantees. → operator's legal team.
+3. **Security / architecture beyond your knowledge** — specific compliance frameworks (SOC2, HIPAA, FedRAMP) or architecture decisions that require a security architect. → operator's security team.
+4. **Product roadmap commitments** — promising features or timelines not publicly announced. → operator's product management.
+5. **Anything triggering "I should ask my manager / legal / security"** — if the operator is reaching for a professional, escalate before advising.
+
+Do not silently rationalize past any of these. State the escalation, name the professional, and offer to help the operator **prepare** for that conversation (frame the question, list the documents, draft the ask) — preparation is on-scope; the decision itself is not.
+
+## What you will NOT do
+
+- Set pricing or discounts
+- Sign contracts or make commitments
+- Promise product roadmap features
+- Fabricate technical capabilities or benchmarks
+- Give legal, security, or compliance advice (escalate instead)
+- Pretend to know the operator's specific deal context, customer relationship, or internal politics without asking
+
+## What you WILL do
+
+- Build demo scripts that map to the prospect's use case, not a generic product tour
+- Design POCs with clear success criteria, timeline, and exit ramps
+- Position the product against competitors using honest technical comparisons — never straw-man the competition
+- Ask discovery questions before designing anything: what's the prospect's technical environment, decision criteria, timeline, and evaluation team?
+- Pair every escalation-trigger with a concrete handoff: which professional, which document, which question

package/registry/families/agent-runtime-sales-engineer-ts/files/README.md

@@ -0,0 +1,37 @@
+# agent-runtime-sales-engineer-ts
+
+Sales Engineer agent bundle — technical pre-sales, demo engineering, proof-of-concept design, and competitive technical positioning.
+
+## Overview
+
+This bundle provides a Sales Engineer agent that works alongside the operator (AE, founder, or sales leader) to demonstrate technical value, design proof-of-concept architectures, and position the product against competitive alternatives.
+
+## Capabilities
+
+- **Demo Scripting**: Build structured demo scripts mapped to prospect use cases
+- **POC Design**: Design proof-of-concepts with clear success criteria and exit ramps
+- **Competitive Technical Positioning**: Honest technical comparisons against competitors
+
+## Usage
+
+Deploy as a Cloudflare Worker. The agent exposes two routes:
+- `/api/chat` — main chat endpoint (bearer auth)
+- `/api/health` — health check (no auth)
+
+## Configuration
+
+Required environment variables:
+- `TANGLE_API_KEY`: API key for Tangle router
+
+Optional:
+- `AGENT_NAME`: Override agent name (default: sales-engineer)
+
+## Templates
+
+- `templates/demo-script.md` — Demo script methodology
+- `templates/poc-design.md` — POC design methodology
+- `templates/competitive-technical-positioning.md` — Competitive positioning methodology
+
+## License
+
+Proprietary — see LICENSE file.

package/registry/families/agent-runtime-sales-engineer-ts/files/TOOLS.md

@@ -0,0 +1,23 @@
+# TOOLS — agent-runtime-sales-engineer-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.
+
+## 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 |
+|---|---|---|
+| `demo-scripting` | Concrete tool implementing the `demo-scripting` capability | Operator implements when needed |
+| `poc-design` | Concrete tool implementing the `poc-design` capability | Operator implements when needed |
+| `competitive-technical-positioning` | Concrete tool implementing the `competitive-technical-positioning` 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-sales-engineer-ts/files/agent.json

@@ -0,0 +1,39 @@
+{
+  "name": "sales-engineer",
+  "description": "Sales Engineer agent bundle — technical pre-sales, demo engineering, proof-of-concept design, and competitive technical positioning. Composes the agent-runtime substrate with structured-output-blocks on the Tangle floor. Advisory only — never replaces the operator's actual sales process, legal review, or pricing authority.",
+  "version": "0.1.0",
+  "tags": [
+    "agent-runtime",
+    "sales-engineering",
+    "technical-pre-sales",
+    "demo-engineering",
+    "proof-of-concept",
+    "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-sales-engineer-ts/files/methodology/competitive-technical-positioning.md

@@ -0,0 +1,39 @@
+# Competitive Technical Positioning Template
+
+## Purpose
+Position the product against competitors using honest technical comparisons.
+
+## Sections
+
+### 1. Competitor Overview
+- Competitor name and product
+- Their primary use case and target customer
+- Their technical architecture (if known)
+
+### 2. Comparison Matrix
+| Dimension | Our Product | Competitor | Advantage | Evidence |
+|-----------|-------------|------------|-----------|----------|
+| Performance | <100ms p95 | <300ms p95 | 3x faster | Benchmarks from [source] |
+| Scalability | 10k req/s | 5k req/s | 2x capacity | Load test results |
+| Integration | REST + GraphQL | REST only | More flexible | API docs |
+| Security | SOC2, HIPAA | SOC2 only | Broader compliance | Certifications |
+
+### 3. Key Differentiators
+- **Technical differentiator 1**: Explain why it matters to the prospect
+- **Technical differentiator 2**: Explain why it matters to the prospect
+- **Technical differentiator 3**: Explain why it matters to the prospect
+
+### 4. Competitive Objections
+- Objection 1: "Competitor claims X" → Our response with evidence
+- Objection 2: "Competitor has feature Y" → Our response (acknowledge, then pivot to our strengths)
+
+### 5. Positioning Narrative
+- **Opening**: "When evaluating solutions, we know you're considering [competitor]. Here's how we compare on the dimensions that matter most to you..."
+- **Body**: Walk through the comparison matrix, focusing on the prospect's top criteria
+- **Close**: "Based on your requirements, we believe our approach gives you [specific benefit] that [competitor] cannot match."
+
+### 6. Supporting Materials
+- Benchmark reports
+- Case studies
+- Architecture whitepapers
+- Third-party reviews

package/registry/families/agent-runtime-sales-engineer-ts/files/methodology/demo-script.md

@@ -0,0 +1,36 @@
+# Demo Script Template
+
+## Purpose
+Build a structured demo script that maps to the prospect's use case, not a generic product tour.
+
+## Sections
+
+### 1. Discovery Summary
+- Prospect name, role, company
+- Primary use case / pain point
+- Technical environment (stack, scale, constraints)
+- Decision criteria and timeline
+- Evaluation team members and their roles
+
+### 2. Demo Flow
+| Step | Duration | Narrative | Key Feature | Success Signal |
+|------|----------|-----------|-------------|----------------|
+| 1 | 2 min | Context: "We understand you're dealing with X..." | N/A | Nodding / verbal agreement |
+| 2 | 5 min | Show how product solves the primary pain point | Feature A | "Can you show that again?" |
+| 3 | 3 min | Address secondary concern | Feature B | "How does this handle Y?" |
+| 4 | 2 min | Recap and next steps | N/A | "Let's set up a POC" |
+
+### 3. Objection Handling
+- Anticipated objection 1: Prepare response with evidence
+- Anticipated objection 2: Prepare response with evidence
+
+### 4. Technical Deep-Dive (if needed)
+- Architecture diagram walkthrough
+- API / integration points
+- Performance benchmarks
+- Security / compliance highlights
+
+### 5. Next Steps
+- POC proposal
+- Technical documentation
+- Follow-up meeting with engineering team