Tobias Oberstein oberstet

A19 — "Complete green-red-green: every transition has exactly one cause, with evidence"

A CI run, a measurement or a deploy outcome is evidence about a change only when exactly one kind of thing changed since the last known outcome. A red with two possible causes proves neither, and a green after two changes cannot say which one made it green.

So every pushed step changes one kind of thing, and its expected outcome is stated before it runs:

Baseline & Harness: Green

Baseline, a no-op change (for example the audit file): expected green.

This is a great concrete example because it gets to a point where "Zenoh runs on microcontrollers" needs some unpacking. The interesting question is not whether Zenoh can run on an MCU, but where you put the Zenoh endpoint and how you bridge between your real-time application core and the networking core.

Your MCXN947 scenario is actually very similar to architectures used in industrial MCUs and heterogeneous SoCs:

                 MCU
+--------------------------------+
|                                |
|  Core 1                        |  Core 0
|  (application)                 |  (communications)

I have a fun idea! often, in "IT pro" meeting (on-line telco) I get bored by the bullshit I am made listening to.

I am not even talking about management talk, but "our lead architect knows better" kinda tech BS.

like for example

https://www.youtube.com/watch?v=40SnEd1RWUU

can you recommend a design and implementation plan for me creating an AI agent driven "BS Bingo MAX" bot, that I can let chime into such a meeting, which then proposes preposterous, funny, but nevertheless technically questions to raise? just or the fun of it. my hope is to survive such meetings by turning them into something entertaining & funny, so that it feels less like a total waste of (my) time?

I have a fun idea! often, in "IT pro" meeting (on-line telco) I get bored by the bullshit I am made listening to. I am not even talking about management talk, but "our lead architect knows better" kinda tech BS. like for example // can you recommend a design and implementation plan for me creating an AI agent driven "BS Bingo MAX" bot, that I can let chime into such a meeting, which then proposes preposterous, funny, but nevertheless technically questions to raise? just or the fun of it. my hope is to survive such meetings by turning them into something entertaining & funny, so that it feels less like a total waste of (my) time?

This is a fantastic (and slightly dangerous) way to survive corporate purgatory. Creating a "BS Bingo MAX" agent requires a mix of real-time speech processing, a Large Language Model (LLM) tuned for "Technobabble," and a clever way to inject audio back into the meeting.

Here is a high-level design and implementation plan for your AI-driven Meeting Disrupter.

	● Grounded in measurement first. Here's what's actually running.

	The chain today, end to end

	jotunheimr_lan host
	└─ systemd-resolved 127.0.0.53 ← also does LLMNR + mDNS ⚠
	└─ DNS → heimdal1:53 (dnsmasq)
	├─ authoritative for jotunheimr.lan (local=/jotunheimr.lan/) ✓
	└─ everything else → 127.0.0.53 on heimdal1 (systemd-resolved)
	└─ upstream = whatever the UPLINK DHCP lease said (router0/FRITZ!Box)

	The numbers tell a clear, compelling story. Here is a breakdown of what the empirical data proves and a couple of subtle technical details to call out in your final report.

	---

	### Key Takeaways & Architecture Validation

	#### 1. TrustZone Overhead & Data Plane Allocation

	* Overhead Math: $\approx 0.57\text{ ms}$ per IPC call.
	* At $1,036\text{ pkt/s}$ (your NSPE ChaCha20 speed), processing $1,036\text{ packets}$ takes about $0.965\text{ ms}$ per packet total.

	● App6 is done, fully green, committed and pushed (6a0ee45) — and the interrupted session turned out to be hiding two genuinely
	important hardware findings. The story:

	What happened after the resume

	The pre-reboot app6 run hadn't just been killed — it had been hung, and the rerun hung at the same spot: the very first write
	to a board console. Diagnosis (py-spy stack dump, /proc fd inspection, kernel queue ioctls, DTR/RTS tests, USB descriptor
	analysis, and the UM12018 board manual):

	1. MCU-Link VCOM is target→host only on our boards. The probe (CMSIS-DAP V3.128, factory firmware r0E7) NAKs every

	● Now the picture is complete and it's a single shared point of failure:

	- All 6 repos clean the PyPI dir with the same reusable action, check-release-fileset@main (keep-metadata: false).
	- 5 of 6 (txaio, zlmdb, cfxdb, wamp-xbr, crossbar) then publish the whole cleaned dir via OIDC packages-dir: dist/ — so they
	all depend on that action producing a truly clean dir.
	- Only autobahn is independently safe, because it uses twine upload dist/.whl dist/.tar.gz (explicit globs).
	- The action's keep-metadata: false uses a denylist that misses build-info.txt. crossbar/cfxdb/wamp-xbr haven't hit it only
	because their builds don't emit that file; zlmdb does.

	So the coherent, reusable fix is one change in wamp-cicd: make check-release-fileset (keep-metadata: false) leave only *.whl

	oberstet@amd-ryzen5:~/scm/typedefint/wampire$ find ~/work/wamp/crossbar/src/ -name "*.py" -exec grep -H "catalog" {} \;
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: # Get catalogs of the current user
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: result = await self.call("xbr.network.get_catalogs_by_owner", member_id.bytes)
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: self.log.info(f"get_catalogs_by_owner results=\n\n{pformat(result)}\n")
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: # Get all catalogs
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: result = await self.call("xbr.network.find_catalogs")
	/home/oberstet/work/wamp/crossbar/src/crossbar/network/test/test_api09_catalog.py: self.log.info(f"find_catalogs results=\n\n{pformat(result)}\n")
	/