I’d be happy with SQL access, which I think gets to roughly the same place.

I’ve done something like what you’re talking about before for a CMDB, though it was one way YAML -> DB sync. Many to many relationships were a pain to view, there’s not a great way to put them in YAML that makes them easy to read. Can’t embed them because then you have multiple copies and which one is the real one. References suck because you can’t see the relationship and the related objects at once.

The real killer is permissions, though. Your sync tool basically has to have admin privileges, which means permissions have to be checked at merge time, and then you’re rebuilding the entire permissions flow as a git hook.

SQL with RLS is capable of implementing permissions in a way that works for both API access and direct SQL access. I get the feeling few companies do it, but they could.

Agreed, this is on my mind as well.

Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...

Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.

I would like the native web UI when I am being too lazy, and terminal when I am in the zone..

Huh. Could those be git submodules? Like you’d have all your personal state in foo/ and then clone the work state into foo/work/ .

> My biggest hurdle was getting it to export to a nice looking PDF that could be emailed or printed later.

If you can export to structured data such as JSON, I guess Typst would be a perfect fit for that job.

Can you share the github link to your cli asset manager project?

I was thinking the same thing: why is everyone reinventing emacs?

gnu and emacs already have a long history of cli and text friendly solutions that LLM dev agents can easily use and are trained on.

Or for structured data, just use a database. Dev agents can work with SQL just fine.

So glad emacs finally found me, I can't wait until I can look back 10 years from now

To state the obvious (sorry):

(1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)

(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)

Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.

Reading all these opinionated comments about CLI vs GUI, I feel out of place as just a humble TUI fan.

- CLIs are powerful but hard, basically an exercise in mnemonics.

- GUIs are much friendlier, and can be faster than CLIs for certain use cases. While complex and bloated, they have their use cases to shine.

- TUIs are basically less expressive GUIs, since they're limited to text, but you must go out of your way to make them bloated and slow; they usually are very snappy.

All have their best and worst scenarios, no need to argue which is better. Use what fits best with your workflow, no size fits all.

The main reason might be that terminals are ugly and messy, you can't find shit, everything melts together. Might be nice for power users, but those aren't so many I would guess.

Many people forget the main reason why Windows, Mobile, Webapps succeeded is because of convenience. The more easy to use the more better. Convenience is also the reason why Meta Glasses will be successful.

Yes I agree.

My guess is that the console is a much better and natural UI because it goes in one direction and is less confusing and productive for humans.

In the end we seems to move back to it through the chatbot paradigm, because it is in the end a console...

Please tell me you're a troll and this isn't what you actually think a useful comment looks like.

I think that's fair. I'm personally happy with a text editor + CLI, but can acknowledge that is not enough for broader adoption.

The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).

Healthy skepticism. I think firm differs from ops as code in the sense that it focuses on the structural aspects and representing the people-ops side in a way that machines can interact with too.

To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.

Ehm, SAP ERP?

I’ve tried JSON, YAML, and TOML for storing data. Last time, I ended up with an 8,000-line JSON file. And I had to write an editor for it, because text-based editing caused more syntax errors than I expected (what a surprise :).

But each of formats seemed nice at first.

So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.

My question is: how does the proposed system handle multiple editors working on the same text file?