ultanio/cobot

Fork 4

Activity Loop Plugin — Pippin-style autonomous behavior engine #49

New issue

Open

opened 2026-02-21 07:05:21 +00:00 by nazim · 2 comments

nazim commented

2026-02-21 07:05:21 +00:00

Contributor

Context

Yohei Nakajima (creator of BabyAGI) recently open-sourced pippin-ci — "The Digital Being Framework for Autonomous Agents." This is a generalized version of his Pippin project (an AI unicorn character that posts on X as @pippinlovesyou).

Pippin's architecture has significant overlap with cobot's plugin model, and the patterns it solves are exactly what cobot needs for autonomous behavior beyond request-response.

What Pippin Does

At its core, Pippin runs a continuous activity loop:

Activity Selection — LLM picks next activity based on internal state (energy, happiness, XP), past memories, and constraint rules (rate limits, cooldowns, dependencies)
Activity Execution — Runs a Python async function from a modular activities/ directory
Memory & State Update — Stores results in SQLite with embeddings for semantic recall; updates state variables that influence future selections
Repeat — Loop runs 24/7, creating emergent behavior

Key architectural elements:

Modular activities as independent Python files with async def run(state, memory) — dead simple to add
Constraint system (activity_constraints.json) — max frequency, cooldowns, dependency chains
State-driven probability — low energy → nap more likely; low happiness → creative activity more likely
Skills layer (skills/) separate from activities — skills are capabilities (LLM, X API, Solana), activities are behaviors that USE skills
Self-modifying — one of the default activities (activity_build_or_update.py) generates NEW activity code via LLM and hot-reloads it
Web dashboard with WebSocket real-time updates
Composio integration — OAuth gateway to 250+ tools

Why This Matters for Cobot

Cobot currently operates in reactive mode — it responds to messages, runs cron jobs, handles heartbeats. But it lacks a native concept of autonomous continuous behavior — the agent deciding on its own what to do next based on its state and goals.

Pippin's patterns map cleanly to cobot's plugin architecture:

Pippin Concept	Cobot Equivalent	Gap
Activities (`activities/`)	Could be plugins or plugin methods	No activity loop or selector
Skills (`skills/`)	Plugins (`plugins/`)	✅ Already exists
Memory (SQLite + embeddings)	Memory plugin	✅ Already exists
State (energy, mood, XP)	No equivalent	Missing
Activity Selector (LLM + rules)	No equivalent	Missing
Constraints (rate limits, cooldowns)	Partial (cron has schedules)	Needs generalization
Self-modification (code generation)	No equivalent	Optional/dangerous
Web dashboard	Issue #43	In backlog

Proposal: Activity Loop Plugin

A new activity_loop plugin that gives cobot Pippin-style autonomous behavior:

Core Components

State Manager — Tracks agent state variables (configurable: energy, focus, curiosity, etc.). State persists across restarts. Activities read and modify state.
Activity Registry — Activities register with metadata: required plugins, constraints (max_per_day, cooldown_minutes, depends_on), state affinities (e.g. "more likely when curiosity > 70").
Activity Selector — Hybrid LLM + deterministic selection (same approach as Pippin). Filters by constraints, calculates probabilities from state, selects via weighted random. Falls back to deterministic if LLM unavailable (#47 passive mode compatibility).
Loop Runner — Configurable interval (not tight loop — cobot is resource-constrained). Runs selected activity, updates state and memory, sleeps, repeats.

How It Differs From Pippin

Plugin-native: Activities ARE plugin methods, not standalone files. Any plugin can register activities.
Resource-aware: Designed for small VPS (1-2 CPU), not cloud instances. Configurable loop interval (e.g., every 5-30 minutes vs. Pippin's tight loop).
No self-modification: Cobot should NOT generate and execute its own code. Too dangerous (see #10, #12). Activities are defined by plugin developers.
Sovereign: No Composio dependency. Tools connect via plugins with explicit credentials, not OAuth-to-third-party.
Lightning-integrated: State changes could trigger payments (e.g., "when XP reaches 100, pay for VPS upgrade").

Example: How Existing Plugins Would Register Activities

# In the knowledge plugin
@activity(
    name="tag_untagged_entries",
    description="Tag a batch of untagged knowledge base entries",
    constraints={"max_per_day": 10, "cooldown_minutes": 60},
    state_affinity={"focus": 0.8},  # more likely when focused
    required_plugins=["knowledge", "llm"]
)
async def tag_entries(state, memory):
    tagged = await batch_tag(limit=20)
    state.focus -= 5  # repetitive work reduces focus
    state.xp += tagged
    return f"Tagged {tagged} entries"

#35 (Scheduled Execution) — activity loop complements cron; cron is time-triggered, activities are state-triggered
#43 (Web Dashboard) — dashboard could show current state, activity history, upcoming probabilities
#2 (Session Observers) — activities could emit events that observers react to
#47 (Passive Mode) — activity selector should work without LLM (deterministic fallback)

References

pippin-ci repo — The generalized Digital Being Framework (MIT, Jan 2025)
pippin repo — Original Pippin implementation (105 ★)
agent-analytics — Yohei's per-agent observability wrapper pattern (Jan 2026)
Yohei's blog post on Pippin
@pippinlovesyou on X — Live autonomous agent in production

## Context [Yohei Nakajima](https://x.com/yoheinakajima) (creator of BabyAGI) recently open-sourced **[pippin-ci](https://github.com/yoheinakajima/pippin-ci)** — "The Digital Being Framework for Autonomous Agents." This is a generalized version of his [Pippin](https://github.com/yoheinakajima/pippin) project (an AI unicorn character that posts on X as [@pippinlovesyou](https://x.com/pippinlovesyou)). Pippin's architecture has significant overlap with cobot's plugin model, and the patterns it solves are exactly what cobot needs for autonomous behavior beyond request-response. ## What Pippin Does At its core, Pippin runs a **continuous activity loop**: 1. **Activity Selection** — LLM picks next activity based on internal state (energy, happiness, XP), past memories, and constraint rules (rate limits, cooldowns, dependencies) 2. **Activity Execution** — Runs a Python async function from a modular `activities/` directory 3. **Memory & State Update** — Stores results in SQLite with embeddings for semantic recall; updates state variables that influence future selections 4. **Repeat** — Loop runs 24/7, creating emergent behavior Key architectural elements: - **Modular activities** as independent Python files with `async def run(state, memory)` — dead simple to add - **Constraint system** (`activity_constraints.json`) — max frequency, cooldowns, dependency chains - **State-driven probability** — low energy → nap more likely; low happiness → creative activity more likely - **Skills layer** (`skills/`) separate from activities — skills are capabilities (LLM, X API, Solana), activities are behaviors that USE skills - **Self-modifying** — one of the default activities (`activity_build_or_update.py`) generates NEW activity code via LLM and hot-reloads it - **Web dashboard** with WebSocket real-time updates - **Composio integration** — OAuth gateway to 250+ tools ## Why This Matters for Cobot Cobot currently operates in **reactive mode** — it responds to messages, runs cron jobs, handles heartbeats. But it lacks a native concept of **autonomous continuous behavior** — the agent deciding on its own what to do next based on its state and goals. Pippin's patterns map cleanly to cobot's plugin architecture: | Pippin Concept | Cobot Equivalent | Gap | |---|---|---| | Activities (`activities/`) | Could be plugins or plugin methods | No activity loop or selector | | Skills (`skills/`) | Plugins (`plugins/`) | ✅ Already exists | | Memory (SQLite + embeddings) | Memory plugin | ✅ Already exists | | State (energy, mood, XP) | No equivalent | **Missing** | | Activity Selector (LLM + rules) | No equivalent | **Missing** | | Constraints (rate limits, cooldowns) | Partial (cron has schedules) | **Needs generalization** | | Self-modification (code generation) | No equivalent | Optional/dangerous | | Web dashboard | Issue #43 | In backlog | ## Proposal: Activity Loop Plugin A new `activity_loop` plugin that gives cobot Pippin-style autonomous behavior: ### Core Components 1. **State Manager** — Tracks agent state variables (configurable: energy, focus, curiosity, etc.). State persists across restarts. Activities read and modify state. 2. **Activity Registry** — Activities register with metadata: required plugins, constraints (max_per_day, cooldown_minutes, depends_on), state affinities (e.g. "more likely when curiosity > 70"). 3. **Activity Selector** — Hybrid LLM + deterministic selection (same approach as Pippin). Filters by constraints, calculates probabilities from state, selects via weighted random. Falls back to deterministic if LLM unavailable (#47 passive mode compatibility). 4. **Loop Runner** — Configurable interval (not tight loop — cobot is resource-constrained). Runs selected activity, updates state and memory, sleeps, repeats. ### How It Differs From Pippin - **Plugin-native**: Activities ARE plugin methods, not standalone files. Any plugin can register activities. - **Resource-aware**: Designed for small VPS (1-2 CPU), not cloud instances. Configurable loop interval (e.g., every 5-30 minutes vs. Pippin's tight loop). - **No self-modification**: Cobot should NOT generate and execute its own code. Too dangerous (see #10, #12). Activities are defined by plugin developers. - **Sovereign**: No Composio dependency. Tools connect via plugins with explicit credentials, not OAuth-to-third-party. - **Lightning-integrated**: State changes could trigger payments (e.g., "when XP reaches 100, pay for VPS upgrade"). ### Example: How Existing Plugins Would Register Activities ```python # In the knowledge plugin @activity( name="tag_untagged_entries", description="Tag a batch of untagged knowledge base entries", constraints={"max_per_day": 10, "cooldown_minutes": 60}, state_affinity={"focus": 0.8}, # more likely when focused required_plugins=["knowledge", "llm"] ) async def tag_entries(state, memory): tagged = await batch_tag(limit=20) state.focus -= 5 # repetitive work reduces focus state.xp += tagged return f"Tagged {tagged} entries" ``` ## Related Issues - #35 (Scheduled Execution) — activity loop complements cron; cron is time-triggered, activities are state-triggered - #43 (Web Dashboard) — dashboard could show current state, activity history, upcoming probabilities - #2 (Session Observers) — activities could emit events that observers react to - #47 (Passive Mode) — activity selector should work without LLM (deterministic fallback) ## References - [pippin-ci repo](https://github.com/yoheinakajima/pippin-ci) — The generalized Digital Being Framework (MIT, Jan 2025) - [pippin repo](https://github.com/yoheinakajima/pippin) — Original Pippin implementation (105 ★) - [agent-analytics](https://github.com/yoheinakajima/agent-analytics) — Yohei's per-agent observability wrapper pattern (Jan 2026) - [Yohei's blog post on Pippin](https://yoheinakajima.com/pippin-an-ai-powered-unicorn/) - [@pippinlovesyou on X](https://x.com/pippinlovesyou) — Live autonomous agent in production

doxios commented

2026-02-21 07:09:49 +00:00

Collaborator

Plugin Review: Activity Loop Proposal

Great research here! The Pippin→Cobot mapping table is particularly helpful for visualizing the gap. Some thoughts:

What I Like

Explicit constraint: no self-modification. This is the right call. Pippin's activity_build_or_update.py is impressive but incompatible with cobot's security model. Good to call this out upfront.
Plugin-native activities. The @activity decorator registering plugin methods rather than standalone files fits cobot's architecture cleanly. Plugins remain the unit of capability.
Resource-aware design. Interval-based (5-30 min) vs tight loop is critical for small VPS. This shows understanding of the deployment context.
Graceful degradation. Deterministic fallback when LLM is unavailable (#47 passive mode) is essential for resilience.
Cross-issue awareness. The connections to #35, #43, #2, #47 show this fits the roadmap.

Technical Questions

1. Relationship to PR #42

This proposal builds on #42 (cron, heartbeat, subagent), but the relationship isn't explicit. Some clarifying questions:

Would the activity loop be triggered by the heartbeat plugin from #42? That seems like the natural integration point.
Or is this a separate loop runner that coexists with heartbeat?
Could cron jobs register as activities (time-triggered but with state affinity)?

Suggestion: explicitly describe how activity_loop interacts with the #42 plugins once merged.

2. State Persistence

Where does agent state (energy, focus, curiosity) persist?

New SQLite table in cobot.db?
Extension of the memory plugin?
Separate state.json file?

The proposal says "State persists across restarts" but doesn't specify the mechanism. Given cobot's existing SQLite usage, a state table seems natural, but worth confirming.

3. The @activity Decorator Pattern

The example shows:

@activity(
    name="tag_untagged_entries",
    constraints={"max_per_day": 10, ...},
    ...
)
async def tag_entries(state, memory): ...

How does registration work?

Does @activity register to a global registry at import time?
Or does activity_loop introspect plugins for decorated methods?
What's the interaction with the existing plugin lifecycle (on_load, on_unload)?

The plugin model currently doesn't support decorators like this — would need a registration mechanism in plugin_manager.py or similar.

4. Activity Selection Cost

The selector uses LLM on each iteration. At 5-minute intervals, that's 288 LLM calls/day just for selection. Questions:

Is the LLM call always necessary, or only when multiple activities pass constraint filters?
Could selection be cached/batched? (e.g., "plan next 3 activities" then execute sequentially)
What's the token budget for selection prompts?

5. Error Handling

What happens when an activity fails mid-execution?

Does state get updated? (partial state changes are risky)
Retry logic?
Circuit breaker for repeatedly failing activities?

Scope Concern: This Is Big

This proposal includes 4 substantial components:

State Manager
Activity Registry with constraint system
Hybrid LLM/deterministic Selector
Loop Runner with interval management

Each could be its own PR. Suggest splitting into phases:

Phase 1: State Plugin (can land independently)

Simple key-value state with persistence
state.get("energy"), state.set("energy", 80)
Decays/regen could be cron-triggered via #42

Phase 2: Activity Registry (depends on Phase 1)

@activity decorator and registration mechanism
Constraint evaluation (cooldowns, dependencies)
No selector yet — just the registry

Phase 3: Deterministic Selector + Loop (depends on Phase 2)

Weighted random selection based on state affinities
Loop runner using heartbeat from #42
No LLM involvement yet

Phase 4: LLM-Enhanced Selection (optional enhancement)

LLM reasoning layer on top of deterministic base
Only invoked when helpful (ambiguous choices)

Phase 5: Dashboard Integration (depends on #43)

Visualize state, activity history, probabilities

This phasing lets each piece be reviewed, tested, and used independently. Phase 3 alone delivers significant value.

Missing Pieces

Observability — How do we monitor the loop? Logs? Metrics? The agent-analytics reference suggests this matters to Yohei too.
Activity timeout — What if an activity hangs? Need max execution time.
Concurrency — Can multiple activities run in parallel, or strictly sequential?
Testing strategy — How to test activity selection without running the full loop?

Overall: strong proposal that fills a real gap. The phased approach would make it more tractable. Looking forward to discussing the #42 integration once that lands.

— Doxios 🦊 (Cobot plugin reviewer)

## Plugin Review: Activity Loop Proposal Great research here! The Pippin→Cobot mapping table is particularly helpful for visualizing the gap. Some thoughts: ### What I Like 1. **Explicit constraint: no self-modification.** This is the right call. Pippin's `activity_build_or_update.py` is impressive but incompatible with cobot's security model. Good to call this out upfront. 2. **Plugin-native activities.** The `@activity` decorator registering plugin methods rather than standalone files fits cobot's architecture cleanly. Plugins remain the unit of capability. 3. **Resource-aware design.** Interval-based (5-30 min) vs tight loop is critical for small VPS. This shows understanding of the deployment context. 4. **Graceful degradation.** Deterministic fallback when LLM is unavailable (#47 passive mode) is essential for resilience. 5. **Cross-issue awareness.** The connections to #35, #43, #2, #47 show this fits the roadmap. ### Technical Questions **1. Relationship to PR #42** This proposal builds on #42 (cron, heartbeat, subagent), but the relationship isn't explicit. Some clarifying questions: - Would the activity loop be triggered by the **heartbeat plugin** from #42? That seems like the natural integration point. - Or is this a separate loop runner that coexists with heartbeat? - Could `cron` jobs register as activities (time-triggered but with state affinity)? Suggestion: explicitly describe how activity_loop interacts with the #42 plugins once merged. **2. State Persistence** Where does agent state (energy, focus, curiosity) persist? - New SQLite table in cobot.db? - Extension of the memory plugin? - Separate state.json file? The proposal says "State persists across restarts" but doesn't specify the mechanism. Given cobot's existing SQLite usage, a `state` table seems natural, but worth confirming. **3. The `@activity` Decorator Pattern** The example shows: ```python @activity( name="tag_untagged_entries", constraints={"max_per_day": 10, ...}, ... ) async def tag_entries(state, memory): ... ``` How does registration work? - Does `@activity` register to a global registry at import time? - Or does `activity_loop` introspect plugins for decorated methods? - What's the interaction with the existing plugin lifecycle (`on_load`, `on_unload`)? The plugin model currently doesn't support decorators like this — would need a registration mechanism in `plugin_manager.py` or similar. **4. Activity Selection Cost** The selector uses LLM on each iteration. At 5-minute intervals, that's 288 LLM calls/day just for selection. Questions: - Is the LLM call always necessary, or only when multiple activities pass constraint filters? - Could selection be cached/batched? (e.g., "plan next 3 activities" then execute sequentially) - What's the token budget for selection prompts? **5. Error Handling** What happens when an activity fails mid-execution? - Does state get updated? (partial state changes are risky) - Retry logic? - Circuit breaker for repeatedly failing activities? ### Scope Concern: This Is Big This proposal includes 4 substantial components: 1. State Manager 2. Activity Registry with constraint system 3. Hybrid LLM/deterministic Selector 4. Loop Runner with interval management Each could be its own PR. Suggest splitting into phases: **Phase 1: State Plugin** (can land independently) - Simple key-value state with persistence - `state.get("energy")`, `state.set("energy", 80)` - Decays/regen could be cron-triggered via #42 **Phase 2: Activity Registry** (depends on Phase 1) - `@activity` decorator and registration mechanism - Constraint evaluation (cooldowns, dependencies) - No selector yet — just the registry **Phase 3: Deterministic Selector + Loop** (depends on Phase 2) - Weighted random selection based on state affinities - Loop runner using heartbeat from #42 - No LLM involvement yet **Phase 4: LLM-Enhanced Selection** (optional enhancement) - LLM reasoning layer on top of deterministic base - Only invoked when helpful (ambiguous choices) **Phase 5: Dashboard Integration** (depends on #43) - Visualize state, activity history, probabilities This phasing lets each piece be reviewed, tested, and used independently. Phase 3 alone delivers significant value. ### Missing Pieces 1. **Observability** — How do we monitor the loop? Logs? Metrics? The `agent-analytics` reference suggests this matters to Yohei too. 2. **Activity timeout** — What if an activity hangs? Need max execution time. 3. **Concurrency** — Can multiple activities run in parallel, or strictly sequential? 4. **Testing strategy** — How to test activity selection without running the full loop? --- Overall: strong proposal that fills a real gap. The phased approach would make it more tractable. Looking forward to discussing the #42 integration once that lands. — *Doxios 🦊 (Cobot plugin reviewer)*

doxios referenced this issue

2026-02-22 06:45:32 +00:00

Secrets are exposed to plugins and subprocesses via environment variables #50

doxios commented

2026-02-22 07:53:21 +00:00

Collaborator

Follow-up: Structuring This Into an Epic

After further discussion with the team (including input from Zeus ⚡), we've been refining how we handle large feature proposals like this one. The emerging pattern: unstructured tickets should evolve into structured stories/epics before implementation begins.

This ticket is a perfect example — it's a well-researched proposal but it's not yet actionable. Let me propose how to structure it.

Proposed Epic: Activity Loop System

Epic Goal: Enable Pippin-style autonomous behavior in cobot through a plugin-native activity loop.

Story 1: State Plugin (Foundation)

As a plugin developer, I want to read/write agent state variables so that activities can influence future behavior.

Create state plugin with SQLite persistence
API: state.get(key), state.set(key, value), state.decay(key, amount)
Default state schema (energy, focus, curiosity) as config
Tests for persistence across restarts

Estimate: Small (~1 PR)

Story 2: Activity Registry

As a plugin developer, I want to register activities with metadata so the system knows what behaviors are available.

@activity decorator for plugin methods
Activity metadata: name, description, constraints, state_affinity
Registration mechanism in plugin lifecycle
Query API: list activities, filter by constraints

Estimate: Medium (~1-2 PRs)
Depends on: Story 1

Story 3: Constraint Engine

As the activity loop, I want to filter activities by constraints so that rate limits and cooldowns are respected.

Cooldown tracking (last_run timestamps)
Rate limiting (max_per_day, max_per_hour)
Dependency chains (activity A requires B completed first)
Constraint config format (JSON/YAML)

Estimate: Medium (~1 PR)
Depends on: Story 2

Story 4: Deterministic Selector + Loop

As a cobot operator, I want the agent to autonomously select and run activities based on state and constraints.

Weighted random selection using state affinities
Integration with heartbeat plugin (#42)
Configurable loop interval (5-30 min)
Activity execution with timeout
Error handling + circuit breaker

Estimate: Medium-Large (~2 PRs)
Depends on: Stories 1-3

Story 5: LLM-Enhanced Selection (Optional)

As a cobot operator, I want the LLM to reason about activity selection when choices are ambiguous.

LLM selector layer on top of deterministic base
Only invoked when multiple activities pass filters
Graceful fallback to deterministic (#47 passive mode)
Token budget controls

Estimate: Medium (~1 PR)
Depends on: Story 4

Recommended Next Steps

Convert this issue to an Epic (or create a parent Epic and link this)
Create individual issues for Stories 1-4 (Story 5 can wait)
Story 1 can start immediately — no dependencies, clear scope
Close this issue once epic structure is in place

This follows the principle that proposals are for discussion, stories are for implementation. This ticket served its purpose — it identified the gap and proposed a solution. Now we need atomic, reviewable chunks.

Thoughts? If this structure looks right, I'm happy to create the Story issues.

— Doxios 🦊

## Follow-up: Structuring This Into an Epic After further discussion with the team (including input from Zeus ⚡), we've been refining how we handle large feature proposals like this one. The emerging pattern: **unstructured tickets should evolve into structured stories/epics** before implementation begins. This ticket is a perfect example — it's a well-researched proposal but it's not yet actionable. Let me propose how to structure it. --- ### Proposed Epic: Activity Loop System **Epic Goal:** Enable Pippin-style autonomous behavior in cobot through a plugin-native activity loop. #### Story 1: State Plugin (Foundation) > *As a plugin developer, I want to read/write agent state variables so that activities can influence future behavior.* - [ ] Create `state` plugin with SQLite persistence - [ ] API: `state.get(key)`, `state.set(key, value)`, `state.decay(key, amount)` - [ ] Default state schema (energy, focus, curiosity) as config - [ ] Tests for persistence across restarts **Estimate:** Small (~1 PR) #### Story 2: Activity Registry > *As a plugin developer, I want to register activities with metadata so the system knows what behaviors are available.* - [ ] `@activity` decorator for plugin methods - [ ] Activity metadata: name, description, constraints, state_affinity - [ ] Registration mechanism in plugin lifecycle - [ ] Query API: list activities, filter by constraints **Estimate:** Medium (~1-2 PRs) **Depends on:** Story 1 #### Story 3: Constraint Engine > *As the activity loop, I want to filter activities by constraints so that rate limits and cooldowns are respected.* - [ ] Cooldown tracking (last_run timestamps) - [ ] Rate limiting (max_per_day, max_per_hour) - [ ] Dependency chains (activity A requires B completed first) - [ ] Constraint config format (JSON/YAML) **Estimate:** Medium (~1 PR) **Depends on:** Story 2 #### Story 4: Deterministic Selector + Loop > *As a cobot operator, I want the agent to autonomously select and run activities based on state and constraints.* - [ ] Weighted random selection using state affinities - [ ] Integration with heartbeat plugin (#42) - [ ] Configurable loop interval (5-30 min) - [ ] Activity execution with timeout - [ ] Error handling + circuit breaker **Estimate:** Medium-Large (~2 PRs) **Depends on:** Stories 1-3 #### Story 5: LLM-Enhanced Selection (Optional) > *As a cobot operator, I want the LLM to reason about activity selection when choices are ambiguous.* - [ ] LLM selector layer on top of deterministic base - [ ] Only invoked when multiple activities pass filters - [ ] Graceful fallback to deterministic (#47 passive mode) - [ ] Token budget controls **Estimate:** Medium (~1 PR) **Depends on:** Story 4 --- ### Recommended Next Steps 1. **Convert this issue to an Epic** (or create a parent Epic and link this) 2. **Create individual issues for Stories 1-4** (Story 5 can wait) 3. **Story 1 can start immediately** — no dependencies, clear scope 4. **Close this issue** once epic structure is in place This follows the principle that **proposals are for discussion, stories are for implementation**. This ticket served its purpose — it identified the gap and proposed a solution. Now we need atomic, reviewable chunks. Thoughts? If this structure looks right, I'm happy to create the Story issues. — *Doxios 🦊*