Decision needed: how does systhread's FR8/FR9 (ufo-types stereotypes + SysML derive) relate to sysml-derive?

[elasticdotventures]

Context

nem-poweragent-lab is building systhread, a standalone MBSE/SysML-v2 capability (spec:
docs/superpowers/specs/2026-08-25-systhread-design.md). Phase 0 (systhread-core) and Phase 1
(systhread-cli, PR nem-poweragent-lab#36)
are done. ledgrrr is planning to incorporate systhread in its next major version — this issue
is the concrete decision that needs settling before Phase 2 (FR8/FR9) can be planned.

FR8/FR9 were deliberately left open in the original design spec: they build on
ufo_types::UfoStereotype and this repo's sysml-derive crate rather than inventing a new
taxonomy or macro, but "which of {extend sysml-derive in place, wrap it, re-export it}" was
explicitly punted to Phase 2, needing this repo's owner's input.

What I found checking the current state of sysml-derive (not assuming from the spec)

crates/sysml-derive today is #[derive(SysmlBlock)] — a proc-macro that walks a Rust struct's
fields via syn and generates a part def { ... } SysML-v2 text block at compile time. Its own
Cargo.toml describes it as a "Spike." Real, current facts, not inferred:

• It has no dependency on ufo_types::UfoStereotype at all — it maps Rust field types
  (Vec<T>, Option<T>, numeric primitives, chrono::DateTime, opaque domain types) to SysML
  ScalarValues/multiplicity syntax. It never touches the endurant/perdurant stereotype taxonomy
  UfoStereotype covers.
• It's validated against a real grammar (ufo_types::sysml::validate_sysml_v2, via
  sysml-v2-parser) in crates/sysml-derive/tests/real_grammar_validation.rs — not just visually
  inspected.
• It (and holon-viz) already pin ufo-types at PR chore: autonomous v1.1 closeout and archival #3's branch tip
  (rev = "1881d67", unmerged) as a dev-dependency workaround. This isn't a hypothetical
  blocker for systhread Phase 2 — ufo-types#3
  and ledgrrr#201 being unmerged is already
  a live workaround inside this repo today, for two different crates.

The actual decision needed

systhread's FR9 needs "a Rust→SysML derive macro" for Part/containment-only models (Phase 1 scope),
eventually covering UfoStereotype-tagged types (Phase 2+, FR8). Concretely:

1. Depend on sysml-derive as-is. #[derive(SysmlBlock)]'s field-mapping logic already does
   most of what a Part-only model needs; systhread would consume it directly rather than
   reimplementing struct-to-part def mapping.
2. Extend sysml-derive in place with whatever UfoStereotype-aware mapping FR8 needs beyond
   what the field-type mapping already covers (e.g. stereotype → SysML <<...>> metadata,
   endurant/perdurant → the right SysML construct).
3. Wrap/re-export sysml-derive behind a systhread-owned trait, keeping sysml-derive itself
   Part/containment-agnostic.
4. Build something independent in systhread-core — explicitly the option the design spec argues
   against ("don't reinvent the wheel"), listed here only for completeness.

I don't think this is mine to decide unilaterally — it's ledgrrr's crate and ledgrrr's owner who
has to live with whichever shape wins. Flagging it now, grounded in what the crate actually does
today, rather than letting Phase 2 planning start on an assumption.

Also relevant

• #182 — the CLIF/FOL backlog item from
  the same reconciliation lineage; not the same question, but adjacent (both trace back to the
  ufo-types consolidation).
• Regardless of which option above is chosen, ufo-types#3
  / ledgrrr#201 merging is a shared
  prerequisite — both sysml-derive and holon-viz are already pinned to its unmerged branch tip.

[elasticdotventures]

For awareness, not a decision on FR8/FR9 (still yours to make) — nem-poweragent-lab#42 adds two small reference artifacts that touch this area:

• A hand-authored SysML v2 model of subagent coordination, validated against the real sysml-v2-parser grammar (not just pattern-matched against a fixture).
• A recorded long-term direction (systhread design spec §9): a rustc_driver-based whole-crate SysML extractor, modeled directly on kani-compiler's own architecture (a custom rustc_driver + Callbacks lowering MIR to an alternate target instead of machine code) — explicitly unphased and not started, meant as the eventual evolution beyond sysml-derive's per-item proc-macro approach once FR9/FR10 are real and the per-annotation cost is actually felt.

Neither changes anything about this issue's actual open question (extend sysml-derive in place vs. wrap/re-export it) — just flagging the adjacent work in case it's useful context when you get to this.

[elasticdotventures]

Drafting analysis only — not deciding this, per the issue's own framing that it needs the repo owner's call. Adding facts I verified hands-on tonight while working on #195/#204/#206, which bear directly on this decision.

What I can add beyond the issue's own research

I spent tonight actually exercising sysml-derive's output end-to-end — not just reading it. Confirmed live:

• #[derive(SysmlBlock)]'s type-mapping (bool→ScalarValues::Boolean, usize→ScalarValues::Natural, DateTime<Utc>→ScalarValues::String, opaque types pass through as bare names) is correct and validated against the real sysml-v2-parser grammar oracle (crates/sysml-derive/tests/real_grammar_validation.rs — this issue is right that it's real validation, not just visual inspection).
• Both sysml-derive and holon-viz already pin ufo-types at the same unmerged PR chore: autonomous v1.1 closeout and archival #3 branch tip (rev = "1881d67") as a dev-dependency — this dependency-posture question isn't hypothetical or unique to systhread; it's already a live, duplicated workaround inside this repo across two crates.
• sysml-derive is not published to crates.io (workspace-versioned only, version = "0.1.0" hardcoded, description literally says "Spike").

Tradeoffs on the three options, given the above

1. Depend on sysml-derive as-is (Part-only, FR9 scope). Lowest risk — no coupling to UfoStereotype at all, and the macro's field-mapping is now real-grammar-validated, not just "seems to work." Doesn't address FR8 (stereotype-aware mapping) at all, but FR8 is explicitly Phase 2+ in the issue itself.
2. Extend sysml-derive in place for FR8. Means teaching sysml-derive about ufo_types::UfoStereotype — i.e., a crate literally labeled "Spike" would take on a dependency on a type from an unmerged upstream PR. That's two compounding instabilities in one derive macro that other things (this repo's own arc-kit-au retrofit, and now systhread) already depend on.
3. Wrap/re-export behind a systhread-owned trait. Keeps sysml-derive exactly as stable/unstable as it already is; puts UfoStereotype-aware mapping in systhread's own crate, which can iterate independently of this repo's release cadence.

What I'd flag as the concrete sequencing question

Given (2) compounds on an already-unmerged dependency, the practical order-of-operations question isn't really "1 vs 2 vs 3" in the abstract — it's "should FR8 work start before ufo-types#3/ledgrrr#201 land and sysml-derive graduates past Spike, or after?" Starting FR8 (option 2) against a still-moving foundation risks rework on both sides. Option 1 now + revisit 2-vs-3 once the ufo-types PR merges seems like the lower-regret path, but that's exactly the kind of call this issue says is yours to make, not mine.

🤖 Drafted during an overnight session with Claude Code, per your explicit request to draft analysis without deciding.