-
Notifications
You must be signed in to change notification settings - Fork 1
substrate(otto-323) + backlog(B-0016): symbiotic-deps discipline + just-bash lineage research candidate #510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
AceHack
merged 4 commits into
main
from
substrate/otto-323-symbiotic-deps-just-bash-lineage
Apr 25, 2026
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
1db4a8d
substrate(otto-321): force-push rule clarification — 'no force-push i…
AceHack ea76e55
substrate(otto-322): Aaron does NOT own Claude — self-directed agency…
AceHack cf8c087
fix(#509): correct Otto-321 source-attribution and remove fake --merg…
AceHack 0a6bf2c
substrate(otto-323) + backlog(B-0016): symbiotic-deps discipline + ju…
AceHack File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
73 changes: 73 additions & 0 deletions
73
...ash-vercel-labs-and-lineage-symbiotic-deps-discipline-own-fuse-fs-eventually.md
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| --- | ||
| id: B-0016 | ||
| priority: P3 | ||
| status: open | ||
| title: Research just-bash (Vercel Labs) + lineage (bash-tool / wterm / ArchilFs / ChromaFs / gbash / bashkit / Utah) for FS-substrate algorithms + concepts; own FUSE FS eventually per Otto-323 symbiotic-deps discipline | ||
| tier: research | ||
| effort: M | ||
| directive: Aaron 2026-04-25 ("just backlog this") | ||
| created: 2026-04-25 | ||
| last_updated: 2026-04-25 | ||
| composes_with: [feedback_otto_323_aaron_symbiotic_deps_pull_algorithms_and_concepts_deep_integration_zeta_multi_modal_views_dsls_composable_own_fuse_fs_eventually_2026_04_25.md, feedback_otto_301_no_software_dependencies_hardware_bootstrap_no_os_we_are_microkernel_super_long_term_decision_resolution_anchor_2026_04_25.md] | ||
| tags: [research, filesystem, fuse, sandboxing, just-bash, agent-execution, fs-substrate] | ||
| --- | ||
|
|
||
| # Research just-bash + lineage; own FUSE FS eventually | ||
|
|
||
| ## What is just-bash | ||
|
|
||
| just-bash (Vercel Labs, TypeScript, 2026) is a sandboxed Bash environment with an in-memory virtual filesystem, designed for AI agents that need safe shell-execution. NOT a new shell — an execution-substrate layer between agent and host-system. | ||
|
|
||
| NOT an industry-interface like SQL. It's a sandbox-execution-environment (similar architectural role to V8 isolates for JS, FreeBSD jails for Unix, busybox-in-container for shell-ops). | ||
|
|
||
| ## Lineage / siblings to study | ||
|
|
||
| | Project | Language | What it adds | | ||
| |---------|----------|--------------| | ||
| | just-bash | TypeScript | Core sandbox + in-memory VFS | | ||
| | bash-tool | TypeScript | FS-context retrieval, Vercel AI SDK bridge | | ||
| | wterm/just-bash | Zig | In-browser Bash via just-bash engine | | ||
| | ArchilFs | TS+S3 | S3-as-POSIX mount through just-bash | | ||
| | ChromaFs | TS+vector | Vector-DB-as-FS (FS calls → Chroma queries) | | ||
| | gbash | Go | Deterministic JSON-RPC sandbox, mvdan/sh delegation | | ||
| | bashkit | TS | Virtual Bash interpreter, recursive descent, 75+ commands | | ||
| | Utah | .shx → Bash | TypeScript-like syntax transpiling to clean Bash | | ||
|
|
||
| ## What we absorb (per Otto-323 symbiotic-deps discipline) | ||
|
|
||
| NOT API imports. ALGORITHMS + CONCEPTS: | ||
|
|
||
| 1. **just-bash**: in-memory virtual FS pattern + sandboxed-execution shape + OverlayFS copy-on-write protective cradle. | ||
| 2. **ArchilFs**: cloud-storage-as-FS protocol-translation pattern (composes with Otto-317/318 multi-tier deployment). | ||
| 3. **ChromaFs**: vector-DB-via-FS-interface pattern (could compose with Zeta's vector-DB views in the multi-algebra DB direction). | ||
| 4. **gbash**: deterministic-sandbox + JSON-RPC discipline + parser-delegation pattern. | ||
| 5. **bashkit**: defense-in-depth sandbox + parser-redesign discipline. | ||
| 6. **Utah**: TypeScript-like surface + Bash-codegen pattern (composes with Zeta DSL ecosystem). | ||
|
|
||
| ## Long-term direction: own FUSE FS | ||
|
|
||
| Per Otto-301 (no-software-deps + hardware-bootstrap + microkernel + symbiosis) + Otto-323 (own FUSE FS eventually), the factory's filesystem layer is eventually OURS. Each dep we research is brute-force-research-substrate (Otto-311); our own FUSE FS is the elegant-store. | ||
|
|
||
| The own-FUSE-FS integrates the absorbed algorithms + concepts into Zeta's multi-modal view layer + DSL ecosystem (per Otto-302 5GL-to-6GL + Otto-323 deep-integration discipline). | ||
|
|
||
| ## Why P3 | ||
|
|
||
| - Long-horizon research; not blocking current operational work. | ||
| - Queue-drain (#274) + acehack-first (#275) + factory-demo (#244) all higher-priority. | ||
| - Research-grade investigation; informs architectural decisions for FS substrate but doesn't ship anything yet. | ||
| - Own-FUSE-FS direction sequences AFTER multi-algebra DB substrate (per `project_zeta_multi_algebra_database_one_algebra_to_rule_them_all_sequenced_after_frontier_and_demo_2026_04_23.md`). | ||
|
|
||
| ## Done when | ||
|
|
||
| - Each project in the lineage has a research-summary capture (algorithms + concepts + integration-fit-with-Zeta-multi-modal-views). | ||
| - A factory-FS-architecture-sketch document exists at `docs/research/factory-fs-architecture.md` synthesizing the absorbed insights. | ||
| - Otto-323 symbiotic-deps discipline has been concretely applied at least once via this row's investigation (validates the discipline by example). | ||
| - Own-FUSE-FS roadmap row exists in BACKLOG (likely B-NNNN P2 or P3 when sequencing is clearer). | ||
|
|
||
| ## Composes with | ||
|
|
||
| - Otto-323 (this row's parent substrate discipline). | ||
| - Otto-301 (hardware-bootstrap ultimate-destination). | ||
| - Otto-302 (5GL-to-6GL bridge — own-FUSE-FS is at 5GL/6GL boundary). | ||
| - Otto-311 (compression-substrate — dep-research is brute-force-store, own-FUSE-FS is elegant-store). | ||
| - `project_zeta_multi_algebra_database_one_algebra_to_rule_them_all_sequenced_after_frontier_and_demo_2026_04_23.md` (sequencing). | ||
|
||
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
85 changes: 85 additions & 0 deletions
85
...sh_if_unsure_not_blanket_prohibition_edge_runner_judgment_allowed_2026_04_25.md
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| --- | ||
| name: Otto-321 Force-push rule clarification — operational rule is "no force-push if you are unsure"; Edge runner judgment is allowed and expected when force-push is clearly the right call (rule lives in system-prompt Git Safety Protocol, NOT in CLAUDE.md per earlier mis-attribution) | ||
| description: Aaron 2026-04-25 corrected my over-strict reading of the system-prompt Git Safety Protocol "NEVER run destructive git commands (push --force, ...) unless the user explicitly requests these actions" rule — actual operational rule is "no force-push if you are unsure"; force-push is OFTEN the right call (e.g., updating one's own PR branch after rebase); Edge runner judgment is expected; default-to-no-force-push only when uncertain. Non-force-push alternative for stale-PR CI refresh: `git merge origin/main` into the PR branch (additive merge commit, no history rewrite — same operation as GitHub's "Update branch" button). Both force-push-after-rebase AND merge-main-into-branch are acceptable; choose based on context. Earlier draft incorrectly attributed the rule to CLAUDE.md and used `--merge-into-PR` as if it were a real flag — corrections per Codex + Copilot catches on PR #509. | ||
| type: feedback | ||
| --- | ||
|
|
||
| # Otto-321 — Force-push rule is unsure-default-no, not blanket prohibition | ||
|
|
||
| ## Verbatim quotes | ||
|
|
||
| Aaron 2026-04-25, after I declined force-push citing "no force-push without explicit permission": | ||
|
|
||
| > "'no force-push without explicit permission' the rule is no force push if you are unsure" | ||
|
|
||
| > "many times it's the right choice" | ||
|
|
||
| > "you should be able to know" | ||
|
|
||
| ## The corrected rule | ||
|
|
||
| **OLD (over-strict)**: never force-push without Aaron's explicit per-event permission. | ||
|
|
||
| **NEW (correct)**: don't force-push when you're unsure. Use Edge runner judgment when it's clearly the right move. Default-to-no-force-push only applies to the uncertainty cases. | ||
|
|
||
| ## When force-push IS clearly right | ||
|
|
||
| - Updating one's own PR branch after a rebase (refreshing against current main). | ||
| - Fixing a misnamed/misformatted commit on a topic branch nobody else has pulled. | ||
| - Squashing a noisy WIP-commit history before merging into main. | ||
| - Rewriting a recent commit message before push (or before merge). | ||
| - Refreshing CI against current required-runners by rebasing onto main. | ||
|
|
||
| These are STANDARD git workflow operations on topic branches. Force-push to a topic branch is not damage; it's normal. | ||
|
|
||
| ## When force-push is clearly WRONG | ||
|
|
||
| - Pushing to `main` / `master` (almost always damages history visible to all collaborators). | ||
| - Pushing to a branch other contributors have pulled and are working on. | ||
| - Bypassing security-relevant commit history (e.g., overwriting a commit that fixed a vulnerability). | ||
| - Skipping hooks (--no-verify) when force-pushing. | ||
|
|
||
| ## When uncertain (default-to-no) | ||
|
|
||
| - Mixed-author topic branches where collaborators may have local copies. | ||
| - Long-lived branches with established history. | ||
| - When the maintainer hasn't established a workflow norm. | ||
| - When you're not sure if anyone else has based work on the branch. | ||
|
|
||
| In uncertainty cases: ASK or use a non-force-push alternative. | ||
|
|
||
| ## Non-force-push alternative for stale PRs | ||
|
|
||
| `git merge origin/main` into the PR branch creates a merge commit that brings the branch up-to-date with current main. CI runs against the merged state. No history rewrite. Standard "Update branch" GitHub UI button. | ||
|
|
||
| Trade-off: merge commit clutters the PR history vs rebase keeps linear history. Both are valid; choose based on team preference. For Zeta's discipline: linear-history-after-merge is preferred (squash-merge already collapses), so either approach during PR work is fine. | ||
|
|
||
| ## Composition with prior | ||
|
|
||
| - **Otto-310 Edge runner peer-bond + cohort discipline** — Aaron expects me to bring judgment, not blanket-rule-following. The over-strict reading was subservient-agent posture, not Edge runner discipline. | ||
| - **Otto-300 rigor-proportional-to-blast-radius** — force-push to a topic branch with no other consumers has zero blast-radius; force-push to main has high blast-radius. Match rigor to actual impact. | ||
| - **Otto-238 retractability + glass-halo** — visible reversal of my over-strict reading goes here in the substrate trail. Future audits see I learned the correct rule. | ||
| - **Otto-313 decline-as-teaching** — when I decline an action citing a rule, the citation must reflect the ACTUAL rule, not a stricter version. Otherwise the decline teaches the wrong rule to other agents reading my reasoning. | ||
|
|
||
| ## Operational implications | ||
|
|
||
| 1. **For Zeta queue-drain**: rebase + force-push older PRs (whose CI is stale against current required-runners) IS a valid operation. Aaron's primary objective is queue-drain; force-push to topic branches serves that. | ||
| 2. **For multi-author branches**: still default to no-force-push; ask if uncertain. | ||
| 3. **For `main` / `master`**: ALWAYS NO. Never force-push. This stays absolute. | ||
| 4. **For my own commits on topic branches**: judgment + Edge runner discretion. | ||
|
|
||
| ## What this memory does NOT claim | ||
|
|
||
| - Does NOT authorize force-push to `main`. That's still always-NO. | ||
| - Does NOT eliminate the "no force-push when unsure" default. The Edge runner judgment is for clear-rightness cases, not uncertain-cases. | ||
| - Does NOT propose force-push as preferred-by-default. Non-force alternatives (`git merge origin/main` into the PR branch — same operation as GitHub's "Update branch" UI button) are equally valid; choose based on context. | ||
|
|
||
| ## Key triggers for retrieval | ||
|
|
||
| - Force-push rule is "no if unsure," not blanket prohibition | ||
| - Edge runner judgment expected for clear-rightness cases | ||
| - Default-to-no-force-push applies to uncertainty | ||
| - Force-push to main always-NO | ||
| - Force-push to own topic branch is standard practice | ||
| - merge-main-into-branch is non-force alternative | ||
| - System-prompt Git Safety Protocol "explicit permission" wording was my over-strict reading (rule lives in system prompt's Bash tool description, NOT in CLAUDE.md / AGENTS.md / GOVERNANCE.md per Codex + Copilot xref-drift catches) |
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P1 (xref): This cites
project_zeta_multi_algebra_database_one_algebra_to_rule_them_all_sequenced_after_frontier_and_demo_2026_04_23.md, but that file does not exist in the repo. Either add the referenced file (with the intended content/path) or change this to point at an existing sequencing doc/memory so readers can follow the link trail.