OlaProis

Done! I just published the full workflow documentation today:

AI Development Workflow: Complete explanation of the process, handover system, how I manage context between sessions

Historical PRDs: The actual Product Requirements Documents used to generate tasks (v0.1.x through v0.3.0)

Task JSON files: How requirements were broken down into implementable tasks via Task Master

Handover templates: The reusable prompts I use to maintain context between AI sessions

Thanks for pushing on transparency, your comment about "open weights vs open source" is a useful framing. The goal is to share enough that someone could reproduce and learn from the approach.

Actually, this is going on the v0.3.0 roadmap. I've been looking for ways to make the standalone mermaid-rs crate genuinely better than just 'mermaid.js but Rust.'

The plan: use %% comments as layout hints. Something like:

%% @pos NodeA 100 200>

Mermaid.js ignores these, so the diagram stays portable. But Ferrite (and anyone using mermaid-rs) could parse them for manual positioning.

You'd be able to drag nodes around in Ferrite, have positions saved to the source, and still share with mermaid.js users (they'd get auto-layout).

If you want to follow progress or have input on the syntax, feel free to open an issue on the repo!

You're right, neither Mermaid nor D2 really nail AWS architecture diagrams out of the box. Mermaid lacks icons entirely, and D2's AWS pack is more 'icons exist' than 'architecture patterns are easy.'

Honestly, this is a gap in the ecosystem. For now, most people either:

- Use draw.io/Excalidraw despite the pain

- Build diagrams programmatically (Diagrams-as-code Python library has good AWS support)

- Just accept text-based flowcharts without icons

If I add custom icon/shape support to Ferrite's Mermaid renderer (v0.3.0+), AWS icons could be a good test case. No promises, but I hear the frustration.

Visual thinking use case makes sense!

The challenge is Mermaid is declarative — layout is computed, not specified. Some options I'm considering:

1. layout hints/constraints in the syntax,

2. export to SVG then use a proper editor like Excalidraw for repositioning. For now, influencing layout via subgraphs and edge ordering is the best workaround."

3. separate system for that, maybe to be included in the crate, would only work in Ferrite in the start

the line is blurry for shure. Code generated by a closed-source compiler (or LSP) is still 'your' code. Maybe the difference is whether humans can reproduce and learn from the process? With traditional code, you can read commit history and understand the author's thinking. With AI-generated code, that context is lost unless explicitly shared. Food for thought.

Great point about sharing the 'how' not just the 'what'. I'll consider adding prompt history or a development log showing the AI interactions, just have to figure out how to present all the data i guess. The commit messages could definitely include more context about what was requested vs generated. Thanks for the thoughtful framing,'open weights vs open source' is a useful distinction

Thanks! TeX math support ($...$ and $$...$$) is planned for v0.4.0. We're going pure Rust (no JS runtimes), targeting common LaTeX syntax. See the planning doc on github (docs folder) for details.

Mobile is definitely a long-term goal, the lightweight binary and native performance would translate well. Your QR-code pairing idea is elegant for non-technical users.

For sync, I've been thinking about:

- Git-based sync for power users (already have git integration)

- Simple local network sync (mDNS discovery, no cloud required)

- Optional relay server, as you described — small binary for hub-and-spoke

The plain-file approach (no proprietary format) makes this tractable since any sync tool works today (Syncthing, Dropbox, etc.). But a native, frictionless solution would be better.

2. Tool Integration API

This aligns with v0.3.0's direction. The plan is:

- Mermaid crate extraction, establishes the modular pattern

- Editor widget as library, opens up embedding

- Command palette / IPC, could expose operations to external tools

For accessibility specifically, what interfaces work well for you? Shell commands? Named pipes? JSON-RPC? Knowing your workflow would help prioritize.

3. Vaults/Profiles

Good point — workspace settings are currently per-folder (`.ferrite/`), but there's no concept of isolated plugin configurations per vault. Added to the consideration list.

Thanks for the detailed feedback!