Logs

Current structure

• /docs/ is the cross-project map and reference index.
• /research/ remains a tile landing page. /software/ is a prose project index rather than a card grid. /worlds/ gives direct entry to generators, local-first play tools, and the NetherWorld project dashboard.
• The former D&D landing page is deprecated. Character Forge and DM Toolkit now sit beside Cosmos and Zork under Worlds.
• The former Tools documentation split has been absorbed into Software and Cosmos documentation.
• The synthCore frontend is retired. A bounded synopsis remains; FerroCore is not presented as a completed replacement.
• /icons/ is a permanent review and testing surface with its own navigation, but no primary-navigation link.

Navigation rule

Grouped choices use one interaction rule: labels are purple at rest; the selected or hovered choice is green. A parent stays selected while one child mode is selected. Cosmos defaults to Galaxy, and Zork Terminal defaults to I.

Open work

The site now has dedicated paths for project documentation, public tools, research records, downloadable software, and browser worlds.

Experimental surfaces

Unlinked routes such as /icons/ can remain as useful test zones or playful artifacts without joining the primary navigation.

Source: Locally.

Published artifact

The human-verified release is available as a public web article and a 16-page letter-size PDF. It organizes its argument across several linked domains and includes inline citations and explanatory figures.

Read Civilizational Costs

Source: Locally.

Related: FerroCore

The platform was a laboratory

TradingView made Pine Script experimentation visible and supplied an audience, but moderation also demonstrated that a public body of work can disappear behind someone else's arbitrarily applied rules. That lesson mattered more than the loss of any single script. The only script that I did manage to publish got less activity in a year than the same script got in hours after the initial launch. Message received; pay money for a premium subscription in order to release open source software - get stonewalled by mods that didn't bother to read my description anyways.

Ownership changed the architecture

My work is still becoming more durable by continuing the metamorphosis into independently controlled Python and Rust systems: normalized events, self-built candles, and paper strategies whose claims can be inspected without placing live orders - and also live order optimization built for the permissionless future. The world seems to have opened up as I am now responsible for everything from the underlying data engine - how that intertwines with the math, and then how it is all organized and visualized. There is room for improvement - not just catching up.

The retained boundary

Alpha TBMC and Beta TBMC can be named and evaluated as public paper strategies brought to you by language model inference combined with a constrained version of my own more personal strategic models expressed roughly in python and converted to rust - a misinterpretation gone well; another iteration not completely my own. I still plan on releasing the underlying TBMC indicator along with it's sisters on Trading View as soon as I can maintain a long enough release schedule as not to offend the moderators on trading view - in the meantime I will be focusing my energy on conversions and open-source optimization outside of walled gardens with rent.

Implemented research system

synthCore normalizes raw-ish trade, quote, and swap events and builds its own interval candles. The core records asset pair, venue, instrument kind, OHLCV, VWAP, source contribution, quality scores, missing-source flags, and out-of-order flags. Optional storage writes queryable candles to SQLite and raw events to compressed daily archives.

The feed workspace contains adapters or runtimes for Binance, Bybit, Coinbase, Hyperliquid, Kraken, OKX, and Uniswap V3. Spot and perpetual instruments are separated in both the event model and storage keys.

Paper-strategy boundary

The control and TBMC layers are paper research. They did not place live orders, hold keys, or take custody. A leaderboard compared rules on the same samples; it did not establish predictive edge or executable performance.

Audit record

The 2026-05-24 read-only audit identified five material correctness risks: late events could replace a complete finalized candle with a late-only fragment; live arrival order conflicted with the deterministic replay contract; directional accounting ignored quantity; basket accounting had unrealistic missing-asset and exposure behavior; and leaderboard JSON lacked proper serialization. That audit did not run tests.

The 2026-06-01 follow-up did run the existing test suites successfully and judged the underlying system legitimate for research and inspection. It also judged the public ranking language too authoritative for the evidence and the strategies useful as probes rather than trading systems.

Current decision

The public frontend is retired until a substantially stronger replacement exists. The normalized-event work, self-built candles, CEX–DEX orderflow analysis, test fixtures, and known failure modes remain part of the record.

Sources: Locally and the project synopsis.

Implemented technical slice

The current source is an execution-research slice, not a portfolio system. ferro-backfill downloads Uniswap V3 swap logs for an explicit pool and block range, preserves block/transaction/log order and raw token deltas, and writes atomic output with a SHA-256 manifest. ferro-quote requests an exact-input QuoterV2 result pinned to a historical block hash and keeps amounts in integer token units.

The code does not contain keys or signing. It does not claim that a candle close was executable, and it does not integrate a treasury or Tri-Pass.

Important implementation/design split

The July source uses an ETH/USDC pool in its first backfill example and contains stable-value accounting from the earlier technical slice. That is test and accounting code, not evidence of portfolio exposure. It must not be mistaken for the newer portfolio direction.

Current design direction

The first real MVP is a dynamic multi-timeframe crypto-native rebalancer with BTC and ETH as the minimum scope. The broader design is a mostly Etherian-focused sector rebalancer. Zero direct stablecoin exposure is being taken seriously after the synthCore-era CEX–DEX orderflow analysis. The indicator conversion is the immediate suite-level work.

Still unresolved

No sector taxonomy, asset list, weighting method, rebalance trigger, benchmark, or hardened strategy specification has been approved. Earlier class lists are research context, not a published FerroCore specification.

Sources: Locally, Technicals, and Design.

Live testnet evidence

The first-generation ETH contracts were deployed on Ethereum Sepolia. The local record reports five complete round cycles and a sweep of more than twenty-five revert paths. It also records seventeen author-driven structured-review findings incorporated into the v1 code.

V2 internal audit

The V2 review covered the abstract lottery, ETH implementation, soulbound badge base, participant and donor badges, and interfaces. Its method moved through architecture, state machine, authorization, external calls, accounting, and liveness, cross-referenced against eleven stated invariants. The report records 39/39 tests passing, including a 1024-run fuzz test; five low-severity and five informational findings; and no high, critical, or medium findings.

V3 hardening pass · 2026-05-22

The V3 pass covered the full ETH/ERC-20 lottery and badge/token family. It added twenty-six checklist-driven tests and records 120/120 tests passing across seven files. Three code fixes were shipped and three design residuals were documented. The report records no high or critical findings in the V3 additions.

Trust boundary

The first-through-fourth reviews are internal development work, not independent assurance. The exact four-pass chronology is not fully normalized into one source file yet. Independent review remains recommended before any mainnet claim, especially for RANDAO economics, maximum-scale gas, the EVL badge registry ceremony, and ERC-20 accounting.

Sources: Locally, the Sepolia demo, and the current audit record.

Current system

The Galaxy Generator samples a small synthetic field and derives a selected system seed from the galaxy seed and star position. Stellar resolves the system. World uses the same seeded core to inspect a selected planet or moon. The Stellar and World pages share generation code so the same inputs agree by construction.

Local development record

The shared rebuild separates deterministic generation, dynamics, coordinate frames, lighting, schemas, and system history from the page interfaces; all eight local Node tests pass as of 2026-07-17. A separate SOL experiment uses Rust/WASM and a pinned JPL Horizons/DE441 snapshot; its six native Rust tests pass. SOL has not replaced the public generators or the site background, and its current integrator is not REBOUND.

Reproducibility

The generators use explicit string seeds and deterministic pseudo-random functions for generated state. Random buttons choose new inputs; once the seed and parameters are fixed, the modeled result is reproducible. The current Galaxy controls sample 400–3,000 stars and expose arm count, arm bias, disk spread, and clumpiness.

Scientific boundary

The output is model-generated, not a catalogue or discovery claim. Labels may describe observed inputs, modeled values, inferences, or aesthetic rendering. The same seed makes a result inspectable; it does not make the result real. The Galaxy page explicitly treats life and biosignature output as uncertain potential rather than confirmed detection.

Publication state

The public tiny-galaxy repository was created on 2026-05-22 and has no GitHub release object. The broader Cosmos integration remains active local website work.

Sources: Cosmos documentation, Galaxy, Stellar, World, and tiny-galaxy on GitHub.

Current: v0.1.21.2

Related: MagmaOS

Rebuilding instead of preserving accidents

Repeated operating-system reinstalls forced a distinction between the environment I intended and whatever state had accumulated on one machine. MagmaOS is the attempt to make the intended environment explicit enough to rebuild. Still I cannot resist the overwhelming urge to craft my own design out of the enormous scrap pile that is the open-source linux ecosystem - we can built some really cool stuff with this shit! And yes - most of all of your life's work is likely 'shit' if you are a career developer. No wonder I could not tolerate 'coding' before. It is not 'Now shit' - it always was - Ignorant fucks like me can just observe it now in real time.

The workspace is part of the tool

Model context, project notes, launchers, screenshots, key handling, themes, and small command-line utilities all affect whether development remains understandable. Reconstructing them exposes assumptions that an uninterrupted installation can hide for years. I also just kinda hate certain assumptions 'people' make. I am happy for you if you feel at home in the TUI, you never need a browser or a GUI to manipulate settings (like a sane person), but some of us just don't like consume hundreds of milligrams of Adderall on a daily basis and still want to escape the encroaching oligopic distopia creeping into the silicon we "own".

The standard

A successful rebuild should restore capability without requiring memory of undocumented gestures. The goal is not constant churn for its own sake; it is confidence that the system can be understood, replaced, and repaired. Currently - we are not meeting the bar. I enjoy this though.

Release record

GitHub records the original v0.1.4 release on 2026-02-28, v0.2.1 on 2026-03-02, v1.0.0 on 2026-03-06, and v1.1.0 on 2026-05-24. v1.1.0 ships archives for x86_64, aarch64, and armv7 plus a SHA-256 manifest; the site mirrors those artifacts.

v1.1.0 changes

Local time replaced elapsed execution time. Disk usage moved from a df subprocess to statvfs64; GPU names moved from lspci to sysfs and pci.ids. Package counting was tightened, short flags became clusterable, unknown short flags began exiting with status 2, and multi-GPU keys became indexed.

Measured context

The release benchmark records roughly 0.8 ms warm-cache for base output and roughly 7.7 ms for all optional fields on the benchmark machine. These are reproducible release measurements from one machine, not universal performance guarantees.

Known metadata mismatch

The current local mirrored changelog labels v1.0.0 as 2026-04-10. That conflicts with the public GitHub release metadata, which says 2026-03-06. The Logs date follows the release metadata; the mirrored changelog still needs correction at its source.

Sources: Project page, the complete GitHub release record, and v1.1.0.

First public release

GitHub records v0.4.3 as published on 2026-04-27. The release includes x86_64, aarch64, and armv7 Linux archives, a Rust source archive, and a SHA-256 manifest. The site mirrors the same release.

Output contract

Directories are shown by default; files, sizes, timestamps, counts, hidden entries, and depth limits are opt-in. Plain whitespace carries hierarchy without box-drawing characters. JSON and Markdown are explicit output modes. There is no configuration or theme layer.

Measured context

The published benchmark compares four real working trees ranging from 35 to roughly 18,000 lines. For equivalent output in that battery, twig records 32–77% fewer cl100k_base tokens than the comparable tree modes. The repository includes the benchmark method and counting script; the result is a measured sample, not a universal guarantee.

Release boundary

v0.4.3 is the published release. Any later local work remains development state until separately versioned and released.

Sources: Project page, release, and benchmark method.

Current record

The honest framing of my Minecraft work is not “systems designer who also made textures.” I wanted to make pixel art. Data-pack mechanics became the vehicle that put the textures into a working object someone could use without compromising respect for the process.

The 2023 catalog included Crimson Bow, Pouches, Nate's Nastier Netherite, Netherscope, Nether Crafting Table, five recipe packs, Infernal Fishing, and Softer Silk Touch. Infernal Fishing built on Dogeon188's Fishing in Lava framework, which deserves direct credit as the ancestor of Infernal Fishing. Softer Silk Touch received four update logs and a same-day fix after a user reported a shears-and-vines conflict - apparently I was on top of things briefly when I had stable shelter and hardware access.

I would not have known how to build those data packs without GPT-3.5. That is not an embarrassing qualification to hide; it is the beginning of the development method that eventually moved far beyond minor edits to standard data-pack formats.

Recovered code and structures

The local audit found the existing Nether Fishing code and assets, both Softer Silk Touch editions, the Pouch assets, the bucket family, and 57 exported NBT structures. The older Warped Structures graph resolves 39 of 39 references. The newer structure graph resolves 15 of 41 references, leaving 26 unresolved.

Compatibility boundary

The maintained source is primarily 1.20.2-era code that requires a syntax refactor for Java 26.2. No current-version compatibility is claimed.

Sources: Project dashboard, GitHub, and Planet Minecraft.