- Prover-Integrated Orchestration Layers (L0-L3): Goedel-Prover-V2 watchdog, BFS-Prover-V2 swarm consensus, bf4prover topology adaptation - FAMM Verilator benchmark: uniform vs preshaped delay comparison (4.4x speedup) - Swarm topological device prober: 11 agents probing traces, caps, delays, errors, vias, PDN - Spec sheet puller: 10 components with key params and topological relevance - Virtual FPGA system tests: 6/6 passed, 134K ops/s throughput - Fixed merge conflicts in AI-Newton test_experiment.ipynb
3 KiB
ENE Hotswappable Plugin Architecture
Status: revamp target / frontline module plan
Purpose
ENE needs a plugin architecture where new data surfaces can be attached, detached, audited, and upgraded without rewriting the core substrate. The TiddlyWiki bridge is the first frontline plugin because it turns the wiki into a live knowledge-capture surface instead of a sidecar document store.
Design Rule
Plugins are not trusted just because they are installed. A plugin must provide:
- a manifest
- a stable plugin id
- declared read/write surfaces
- an explicit settlement policy
- deterministic receipts for each write
- dry-run mode
- idempotent ingest behavior
- a quarantine path for unknown or oversized content
Plugin Lifecycle
discover: read plugin manifests from known plugin directories.load: import the plugin module and check its declared interface version.admit: verify that requested surfaces match the manifest.scan: collect source records and compute source receipts.plan: produce intended ENE package writes without mutating state.commit: write packages, receipts, links, and plugin state.verify: re-read written records and compare receipts.unload: close file handles and release watcher resources.
Minimal Plugin Manifest
{
"plugin_id": "ene.tiddlywiki.bridge",
"version": "0.1.0",
"interface_version": "ene-plugin-v0",
"entrypoint": "tiddlywiki_ene_bridge.py",
"surfaces": {
"reads": ["6-Documentation/tiddlywiki-local/wiki/tiddlers"],
"writes": ["data/substrate_index.db"]
},
"capabilities": [
"scan",
"dry_run",
"ingest",
"receipt",
"incremental_state"
]
}
TiddlyWiki Bridge Role
The bridge watches or scans .tid files, parses field headers and body text,
then upserts one ENE package per tiddler. It does not embed the entire
TiddlyWiki runtime inside ENE. Instead, it embeds the TiddlyWiki data surface:
- title
- tags
- type
- modified/created timestamps
- body hash
- source path
- wiki links
- concept anchor
- ConceptVector14-style route vector
- plugin receipt
This lets TiddlyWiki remain a good human editing surface while ENE remains the truth substrate for search, provenance, and settlement.
Package Shape
Package id:
ene/tiddlywiki/<slug>
Version:
<modified timestamp or file mtime>-<content hash prefix>
Concept anchor:
{
"domain": "wiki",
"concept": "<slug>",
"resolution": "FORMING",
"source_plugin": "ene.tiddlywiki.bridge"
}
Verification basis:
tiddlywiki_bridge_receipt:<sha256>
Quarantine Rules
The plugin must refuse or quarantine:
- active script content
- tiddlers over the configured byte limit
- missing titles
- malformed field blocks
- package writes that cannot be re-read
Near-Term Path
The current implementation is a standalone Python module. During the planned ENE revamp, it should become the reference plugin for:
- plugin discovery
- dry-run planning
- receipt shape
- incremental state
- hotswap load/unload
- TiddlyWiki-to-ENE ingestion