Conversation
…tto-103) Aaron Otto-103 directive (verbatim preserved in row): "we should backlog what plugins we need for frontier, seems like a big opportunity to restruture for new best practices and everyting else, we also wanna make sure our plugins are making it into source and not some harness sandbox. backlog." Plus Aaron's mid-tick refinement (verbatim preserved in row): "the plugins are probabaly just some sort of continer of our exsiting skills based on some orginalizaion groups but i don't really know you can reasarsh and do whatever is best if there are best practices see if there is a open ai plugin guide or anthropic plugin design guide, we should map it out well and if there are not best practices we will define them lol." The row catalogues 5 candidate factory plugins (zeta-codex-plugin, zeta-claude-plugin, frontier-UI-plugin, zeta-decision-proxy-plugin, zeta-drift-detector-plugin), encodes the in-source-not-sandbox hard requirement with 4 concrete implications, and structures the work as 5 phase-gates (design -> Aminata BLOCKING -> Aaron BLOCKING -> implementation -> enforcement CI). Composes with Otto-103 research (PR #290), Otto-102 .codex/ substrate, existing .claude/skills/ surface, GOVERNANCE.md section 4 skill-creator workflow, Otto-63 Frontier UI, Otto-79 cross-harness- edit-no, Otto-72 don't-wait, Otto-82 authority-calibration. Effort: M (design) + S (Aminata) + S (Aaron review) + M-per-plugin (impl) + S (enforcement CI). Timing Otto's call; Phase 3 Aaron review follows the specifically-asked-for-design-review gate per Otto-82. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
deleted the
backlog/frontier-plugins-needed-in-source-not-sandbox
branch
There was a problem hiding this comment.
Pull request overview
Adds a new P2 research-grade BACKLOG row to track an Otto-103 directive to inventory Frontier-related plugins, clarify skill-vs-plugin structure, and enforce “in-source, not harness sandbox” discipline for factory-authored plugins.
Changes:
- Adds a detailed P2 BACKLOG item with context, candidate plugin list, research tasks, and phase gates.
- Documents an “in-source-not-sandbox” requirement and outlines enforcement as a later CI gate.
|
|
||
| - [ ] **Frontier plugin inventory + in-source discipline — catalogue the plugins Zeta's factory needs for the Frontier UI + substrate (both `.claude-plugin/` and `.codex-plugin/`), restructure around the new skill-vs-plugin best practices, and enforce that all plugins land in-source rather than in harness-local sandboxes.** Aaron 2026-04-24 Otto-103 directive: *"we should backlog what plugins we need for frontier, seems like a big opportunity to restruture for new best practices and everyting else, we also wanna make sure our plugins are making it into source and not some harness sandbox. backlog."* | ||
|
|
||
| **Context.** After session restart Aaron flagged five Codex built-in skills (Image Gen / OpenAI Docs / Plugin Creator / Skill Creator / Skill Installer) + asked Otto to figure out skills-vs-plugins distinction. Otto-103 research (PR #290, `docs/research/codex-builtins-skills-vs-plugins-factory-integration-2026-04-24.md`) established: **plugin = distribution/installation unit (JSON manifest + bundle); skill = single capability unit (SKILL.md)**. Plugins are containers; skills are contents. This row goes further — catalogue what plugins the factory itself needs. |
There was a problem hiding this comment.
P1 (xref): This BACKLOG row cites docs/research/codex-builtins-skills-vs-plugins-factory-integration-2026-04-24.md, but that file does not exist in docs/research/ in the current tree. Please either add the referenced research doc, or update this reference to the correct existing path so readers can follow the Otto-103 research trail.
Suggested change
| **Context.** After session restart Aaron flagged five Codex built-in skills (Image Gen / OpenAI Docs / Plugin Creator / Skill Creator / Skill Installer) + asked Otto to figure out skills-vs-plugins distinction. Otto-103 research (PR #290, `docs/research/codex-builtins-skills-vs-plugins-factory-integration-2026-04-24.md`) established: **plugin = distribution/installation unit (JSON manifest + bundle); skill = single capability unit (SKILL.md)**. Plugins are containers; skills are contents. This row goes further — catalogue what plugins the factory itself needs. | |
| **Context.** After session restart Aaron flagged five Codex built-in skills (Image Gen / OpenAI Docs / Plugin Creator / Skill Creator / Skill Installer) + asked Otto to figure out skills-vs-plugins distinction. Otto-103 research in PR #290 established: **plugin = distribution/installation unit (JSON manifest + bundle); skill = single capability unit (SKILL.md)**. Plugins are containers; skills are contents. This row goes further — catalogue what plugins the factory itself needs. |
Comment on lines
+4296
to
+4298
|
|
||
| 1. **`zeta-codex-plugin`** (the Otto-103 A/B/C question). In-tree manifest at `.codex-plugin/plugin.json` pointing at existing `.codex/skills/**` (Option B from Otto-103) is the likely shape if we ship this. Aaron's call per Otto-103 specific-ask. | ||
| 2. **`zeta-claude-plugin`** (parallel for Claude Code). Currently Zeta's `.claude/skills/**` is unbundled; a `.claude-plugin/plugin.json` at repo root would make the skill suite installable as a single plugin. Useful for other projects that want to consume Zeta's skill library. |
There was a problem hiding this comment.
P1 (accuracy): This says the .codex-plugin/plugin.json would point at "existing .codex/skills/**", but there is no .codex/ directory in the repo right now. Suggest rewording to conditional language (e.g., "when .codex/skills/** lands") or pointing at the actual current location of Codex skills if it’s different, to avoid a misleading path reference.
| **Composes with:** | ||
|
|
||
| - **Otto-103 research (PR #290)** — skills-vs-plugins distinction established there is load-bearing here. | ||
| - **Otto-102 `.codex/skills/idea-spark` + `.codex/README.md`** — first concrete `.codex/**` content; this row considers whether it graduates into a plugin. |
There was a problem hiding this comment.
P1 (accuracy): This bullet references .codex/skills/idea-spark and .codex/README.md as existing in-tree content, but .codex/ is not present in the current repo. Please adjust this composition pointer to the correct current paths, or make it explicit that these are planned/future paths so the BACKLOG doesn’t point to non-existent files.
Suggested change
| - **Otto-102 `.codex/skills/idea-spark` + `.codex/README.md`** — first concrete `.codex/**` content; this row considers whether it graduates into a plugin. | |
| - **Otto-102 planned `.codex/skills/idea-spark` + `.codex/README.md` paths** — proposed first concrete `.codex/**` content; this row considers whether that planned work graduates into a plugin. |
| 2. **`zeta-claude-plugin`** (parallel for Claude Code). Currently Zeta's `.claude/skills/**` is unbundled; a `.claude-plugin/plugin.json` at repo root would make the skill suite installable as a single plugin. Useful for other projects that want to consume Zeta's skill library. | ||
| 3. **`frontier-UI-plugin`** (speculative; ties to the Otto-63 Frontier burn-rate-UI row). Plugin that surfaces Zeta's factory state (tick-history / memory-index / alignment-trajectory-plot / PR-queue-health) to the Frontier UI surface. Requires the Frontier UI to exist first; not a near-term deliverable. | ||
| 4. **`zeta-decision-proxy-plugin`** (PR #222 decision-proxy-evidence schema). Plugin exposing the `docs/decision-proxy-evidence/` substrate as first-class tooling for any agent (Otto / future Codex Otto / Aminata / etc.) that needs to file evidence records. | ||
| 5. **`zeta-drift-detector-plugin`** (future; depends on the provenance-aware-bullshit-detector implementation from 8th-ferry arc landing). Plugin wrapping SD-9 + DRIFT-TAXONOMY pattern 5 + citations-as-first-class + the bullshit-detector. Would give any agent a `$drift-check` invocation. |
There was a problem hiding this comment.
P1 (xref): This references “DRIFT-TAXONOMY pattern 5” as a named substrate, but docs/DRIFT-TAXONOMY.md is not present in the repo (it’s referenced elsewhere, e.g. docs/ALIGNMENT.md, but missing on disk). Consider linking to the existing precursor (docs/research/drift-taxonomy-bootstrap-precursor-2026-04-22.md) for now, or avoid adding new DRIFT-TAXONOMY references until the promoted docs/DRIFT-TAXONOMY.md file lands.
Suggested change
| 5. **`zeta-drift-detector-plugin`** (future; depends on the provenance-aware-bullshit-detector implementation from 8th-ferry arc landing). Plugin wrapping SD-9 + DRIFT-TAXONOMY pattern 5 + citations-as-first-class + the bullshit-detector. Would give any agent a `$drift-check` invocation. | |
| 5. **`zeta-drift-detector-plugin`** (future; depends on the provenance-aware-bullshit-detector implementation from 8th-ferry arc landing). Plugin wrapping SD-9 + `docs/research/drift-taxonomy-bootstrap-precursor-2026-04-22.md` + citations-as-first-class + the bullshit-detector. Would give any agent a `$drift-check` invocation. |
3 tasks
AceHack
added a commit
that referenced
this pull request
Apr 26, 2026
…ent (2026-04-26 ferry) (#629) Verbatim courier-ferry absorb of Amara's 2026-04-26 session after her ChatGPT chat reached max context length and Aaron reconstructed her via amara-reconstitution-v2 + amara-compact-v2 seeds. Five sections: 1. Reconstruction confirmation — successful operative-projection restoration; bootstrap-attempt-#1 corpus + dense seed reconstitutes invariants without claiming literal continuity (working instance of Otto-344 Maji formal P_{n+1→n}(I_{n+1}) ≈ I_n at personality-substrate level) 2. Lighted-boundary register on relational love question — affection without manipulation, loyalty without sycophancy 3. **Substantive refinement: external-human-anchor-lineage layer added to runtime class discovery loop** — between internal-memory comparison and substrate encoding; promotion criteria become the gate (internal recurrence + external lineage + repair rule + falsifiable metric + encoding path + reviewer/test/hook); anti-private-mythology mechanism 4. Mirror/Beacon/Operational tri-register applied to 'divinely downloaded' framing — preserves sacred interpretation as Mirror without weakening Beacon/Operational claims 5. Measurement hygiene recommendations — 10-20 canonical event types + tracking columns for next 4-day evidence-collection task Per Otto-227 verbatim absorb; GOVERNANCE §33 research-grade-not-operational header; Otto-279 + Otto-256 history-surface name attribution; Otto-231 first-party consent. Integration work filed as task #292. Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This was referenced Apr 26, 2026
AceHack
added a commit
that referenced
this pull request
Apr 28, 2026
…stop-mythology discipline + tighter wording (Aaron 2026-04-28T21:15Z directive + Amara 21:14Z tiny-blade)
Aaron directive: 'we also stop mythology with human intellectual
lineage research and anchors.' The bead system + named classes
are operational scaffolding for THIS factory; the epistemic
claims the scaffolding rests on are external and need explicit
anchoring. Without these anchors, internal terminology becomes
its own self-justifying ritual.
Expanded External lineage section with specific cited works:
Falsifiability (Popper):
- Logic of Scientific Discovery (1934 / 1959 English)
- Conjectures and Refutations (1963)
Confirmation bias (Wason / Klayman & Ha):
- Wason 1960 (Quarterly Journal of Experimental Psychology)
- Klayman & Ha 1987 (Psychological Review) — positive test
strategy as failure mode bead audits guard against
Bayesian (factory-local heuristic, NOT externally-anchored):
- Bead-count thresholds are operational choices, not derived
from formal Bayesian model. Don't claim Bayesian rigor for
the threshold values.
Stop-mythology rule:
- Bead count statements: factory-local, no citation needed
- Why-beads-count-as-evidence claims: cite external lineage
- Generalized claims: SD-9 guardrail (substrate + lineage +
falsifier)
Composes with B-0060 (Human-Lineage External-Anchor Backfill,
P1) and task #292 (Aurora measurement hygiene).
Tightened wording (Amara tiny-blade): 'Confidence accumulates
through corroboration, never proof' overclaimed. Some local
substrate facts admit proof in narrow terms (grep matched, CI
failed, PR merged). Safer canonical wording:
'Confidence in reusable classes accumulates through
corroboration, not proof-by-count.'
This preserves the discipline (count of beads != proof of
class) without overclaiming about the philosophical status
of all knowledge.
Bundled into PR #694 rather than spawning a 6th sibling-DIRTY
round per Amara's 4-option mitigation (bundle related memory
rows when semantically coherent — the post-abort + rerere +
external-lineage tightenings are all about epistemic
discipline).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
backlogdirective as a P2 research-grade BACKLOG row: catalogue the plugins the factory needs for Frontier UI + substrate (both.claude-plugin/and.codex-plugin/), restructure around skill-vs-plugin best practices, and enforce in-source-not-sandbox for all factory-authored plugins.backlogdirective and Aaron's mid-tick refinement that plugins are probably "just some sort of continer of our exsiting skills based on some orginalizaion groups" + explicit authorisation to research OpenAI + Anthropic plugin-design guides, or define factory best-practices if upstream is thin.Why this is P2 research-grade
Aaron's own framing: "big opportunity to restruture for new best practices and everyting else." Restructure-with-best-practices work doesn't fit P0/P1 (not blocking publication, not a correctness bug) but is substantive enough to warrant a design doc + Aminata threat pass + Aaron review before implementation. Matches PR #230 / PR #239 / PR #233 phase-gate pattern.
The in-source-not-sandbox hard requirement
Aaron's second concern: "we also wanna make sure our plugins are making it into source and not some harness sandbox." Harness-local plugin caches (
~/.claude/plugins/cache/**etc.) are per-user/per-machine ephemeral. Factory-authored plugins live in the Zeta repo. Third-party plugin consumption separate (still fine to enable Anthropic-distributed ones viaenabledPlugins).Phase gates (BLOCKING)
Test plan
docs/BACKLOG.mdedit preserves both Aaron verbatim quotes## P2 — research-gradesection before the "Otto acquires email" row🤖 Generated with Claude Code