SEED

Definition: A fleshed-out concept, idea, or project in development — not yet ready for operational execution. Can also remain a SEED forever as a catalogued concept without needing to go anywhere.

Characteristics: - Has structure: problem statement, context, key questions, knowns/unknowns - Lives indefinitely as a catalogued artifact - Graduation is optional, not required - When it does graduate, the SEED doc persists and gets linked to the evolved entity

Lifecycle: SEED → (may graduate) → SPROUT (or remain SEED forever)

Relationship to SPARK: - A SPARK may “unfold” into a SEED as a separate document - Both exist independently after the unfolding - The SPARK gets tagged with evolved_into: SEED-XXX - The SEED gets tagged with evolved_from: SPARK-XXX

Example:

# SEED: Non-interactive Agent Access Architecture
**Filed:** 2026-05-13
**Status:** ACTIVE
**Type:** SEED
**Associations:**
  - evolved_from: [SPARK-001]
  -Evolves into: [SPROUT-001]
  - Related: [POD-XXX]
**Problem:** Tailscale SSH intercept blocks SSH-based tooling for non-interactive
  agent sessions. Remote operations that depend on ssh/scp/rsync fail.
**Context:** All six Forgejo repos affected. Agents cannot run remote commands
  via ssh relik-pi4 <command>. Workaround uses Forgejo HTTP API but leaves
  other remote tasks inaccessible.
**Key Questions:**
  - What is the full scope of blocked operations?
  - Is Tailscale SSH the only path or are there alternatives?
  - What does a viable long-term access architecture look like?
**Known:**
  - Tailscale web auth intercept is the blocker
  - Forgejo API works as fallback for repo ops
  - pi-starter-pack issue #8 tracks this
**Unknowns:**
  - ACL configuration options
  - Non-interactive key auth feasibility
**Tags:** #infra #access #tailnet #agents