I've been working on a pytest-first acceptance testing framework called Dokimasia (do-kee-ma-see-ah) that I'd love to get your thoughts on: https://github.com/deevus/dokimasia

Acceptance testing might not be what you need for Forge, but since you're deep in AI tool building I thought you may have opinions.

I've been using it as part of a complex DOS game decompilation project[0]. I'm working on refactoring the software rendering pipeline so that we can add GPU rendering. The hardest part of this so far is converting the 90's polygon rendering from screen to world space.

It spun its wheels a few times doing a large mostly mechanical change. After resetting and improving my prompts it was able to get through it. I'm using Matt Pocock's skills[1] for this work, which has been quite nice.

[0]: https://github.com/FatalDecomp/ROLLER

[1]: https://github.com/mattpocock/skills

Type: Contract or FT

Remote: Yes

Willing to relocate: No

Technologies: Python, Zig, Rust, Go, TypeScript, Laravel/PHP, Django, AWS, Terraform, Docker; Tauri, Flutter; Ghidra/reverse engineering, cryptography (OpenSSL, libsodium)

Resume: https://www.linkedin.com/in/deevus/

GitHub: https://github.com/deevus (~5,000 contributions in the last 12 months)

Email: simon (at) simonhartcher.com

I run a solo consultancy out of Wollongong. Recent work: built a zero-trust key management system in Zig with a Python middleware layer for Byterix Labs (Singapore, scam prevention), spent twelve months on SwitchDin's platform team optimising Python ETL and Django (Newcastle, distributed energy resources), and ship a cross-platform Rust + React desktop disk cleaner called Reclaimr. Before that, eight years at Bonjoro: first senior engineering hire through to CTO, running a team of six on AWS Lambda + MySQL Aurora + Redis. Co-founder of gdzig (Zig bindings for Godot, 180 stars) and co-founding maintainer of Scoop (24k+ stars). Two front-page HN posts this year on Apple Silicon vs Framework laptops and applying Andrew Kelley's "Programming Without Pointers" technique to a real Zig project.

It currently only exposes a rudimentary set of tools which I’d like to expand. The sandboxes created by MCP are generally ephemeral. The daemon will clean them up after an hour of no usage.

But it’s so cool that they get their own IP and you can ssh straight in. I can see that being very useful when you want to share with a colleague and then close your laptop (assuming it’s running on a remote instance).

https://github.com/deevus/pixels

Comments URL: https://news.ycombinator.com/item?id=47776173

Points: 1

# Comments: 0

It supports running on a TrueNAS SCALE server, or via Incus (local or remote). I'm still working on tightening the security posture, but for many types of AI workflows it will be more than sufficient.

  Location: Wollongong, Australia (UTC+10/+11)
  Remote: Yes
  Willing to relocate: No
  Technologies: Zig, C, Terraform, Docker, Linux, Go, Python, Laravel, Node, React, TypeScript, Flutter/iOS, Godot, PostgreSQL, AWS
  Resume/CV: https://github.com/deevus
  Email: See GitHub profile
  LinkedIn: https://linkedin.com/in/deevus

Recent work and open source:

- Scoop - Windows CLI installer (https://github.com/ScoopInstaller/Scoop)

- TrueNAS Terraform provider and Go client: https://github.com/deevus/terraform-provider-truenas

- Pixels - disposable Linux containers for AI coding agents: https://github.com/deevus/pixels

- Cryptographic protocol implementation in Zig (OpenSSL FFI) for fraud prevention

- Godot bindings for Zig: https://github.com/gdzig/gdzig

- compile_flagz (C/C++ IDE integration for Zig builds): https://github.com/deevus/compile_flagz

- Games on itch.io (https://doubleword-labs.itch.io), developing Parasite Attack 1984 for Steam (https://store.steampowered.com/app/3245960/Parasite_Attack_1...). Siligong Valley game-dev organiser

Looking for: contracts (short or long-term) or full-time remote. Interested in infrastructure tooling, dev tools, systems programming, or anything Zig-adjacent. 4-day workweek is a plus.

I used Claude Code extensively but this is NOT vibe coded! I review every line of code. I might have missed some corkers when developing this at midnight.

It is using a bit of trickery to support checkpoints of the Incus containers. The main reason for this was so that you can spin up a base container, install everything you want, and then create a new container from that.

I did try to make the sandbox secure. I think I can do a better job there. Opus is actually pretty good at escaping a sandbox if you ask it to. Read the details in SECURITY.md.

In future I would like to provision the base container as part of the setup, to help speed up subsequent creates.

I'm not totally sold on the name. It was just the first thing I thought of. I don't know if this is even something others would want to use, but it scratches an itch for me.

---

A bit of backstory:

Over the last couple of months I have been working on a Terraform provider for TrueNAS SCALE [0] and it occurred to me that all this work could be extracted into a client library [1]. I wanted to play around with vaxis [2], so I created a basic TUI that you can use to monitor your TrueNAS server [3].

[0]: https://github.com/deevus/terraform-provider-truenas

[1]: https://github.com/deevus/truenas-go

[2]: https://github.com/rockorager/vaxis

[3]: https://github.com/deevus/truenas-tui

Comments URL: https://news.ycombinator.com/item?id=47179403

Points: 1

# Comments: 0

I'm glad that works for you. My (and my wife's) ADHD brains put these directly into "the void".

I find that brainstorming + (executing plans OR subagent driven development) is way more reliable than the built-in tooling.

1. Use brainstorming to come up with the plan using the Socratic method

2. Write a high level design plan to file

3. I review the design plan

4. Write an implementation plan to file. We've already discussed this in detail, so usually it just needs skimming.

5. Use the worktree skill with subagent driven development skill

6. Agent does the work using subagents that for each task:

  a. Implements the task

  b. Spec reviews the completed task

  c. Code reviews the completed task

8. Go back to the agent with any comments

9. If finished, delete the plan files and merge the PR

[0]: https://github.com/obra/superpowers