[tracking] upstream feature ports worth considering for the interop fork

[PYDuquesnoy]

Tracking issue from the upstream audit (302 commits since divergence 3664671, upstream now at v1.0.0). These are features, not fixes — each is a deliberate scope decision for the lean interop fork. Ranked by fit:

Strong fit

• 056 interop-depth (f92da6d): iris_message_body (read Ens.StringContainer/StreamContainer/%Stream bodies — the natural completion of our [interop_query] no typed way to search on message CONTENT — body-class join and Search Tables #4 message-content search), iris_business_rule_info (list/get vs Ens.Rule.RuleSet — maps directly onto the RUL component type our skills teach), iris_production_diff (running config vs SCM-committed source). Note: upstream's version gates message bodies behind its PHI dataPolicy subsystem, which we don't have — port with a simpler size-capped/plain output.
• 064 iris_coverage (3cc8859): ObjectScript line coverage — pairs directly with our TDD-first workshop workflow (%UnitTest gate).
• 070 symbols_local overhaul (728c1be..d6fcf55): BPL/DTL XData support, structured FormalSpec in docs_introspect, 12 member kinds, line numbers. Interop-relevant (BPL/DTL introspection).

Medium fit

• 071 iris_execute session state (6349e06): %ctx carrier so consecutive iris_execute calls share state — addresses a real agent pain (variables "disappearing" between calls; related to how [interop] iris_execute ignores IRIS_NAMESPACE from the MCP server env and silently runs in USER #15 surfaced).
• 057 sql-power (ef115cd): explain/count/write modes for iris_query.
• d3bc028 MCP ToolAnnotations: readOnly/destructive hints on every tool — cheap, protocol-level, lets clients gate confirmation UX properly.
• 065 iris_doc_search (2df6794): Algolia-backed docs.intersystems.com search — handy for students.
• positional edits + diff display (0947049 + 203465e): insert/delete_lines modes for iris_doc — big token savings on large classes; also what makes [scm] port upstream's source-control session rework as one unit — our scm.rs is verbatim pre-rework; approved checkouts are never committed; IsEditable can report editable=false on healthy docs #19's CheckoutCache pay off.

Poor fit — recommend explicitly NOT porting (recorded so we don't re-litigate)

• 072 multi-instance pool / WebSocket sessions, 073 destructive gate + 074 write allowlist, 051 PHI policy subsystem, 044 Server Manager discovery/keychain, 061 skill-pack CLI, 059 benchmark harness, 063 CLI shortcuts, 052 iris_global, 053 doc-depth, 055 admin observability — each adds a subsystem the lean fork deliberately dropped, or duplicates what iris-interop-skills already covers.

Related fix-port issues from the same audit: #17 (search), #18 (iris_doc), #19 (SCM rework), #20 (iris_debug), #21 (connection/config), #22 (executor), #23 (security/deps).

[PYDuquesnoy]

Re-sync assessment (2026-08-24) — measured, not estimated

Upstream shipped v1.2.0–v1.2.4 while we were on 0.7.x, and every patch we sent them landed: issues #92/#95/#96/#97/#98/#99 closed as completed, PR #93 merged, and PRs #100/#101 closed with "Already merged directly as 90793f9 / 09047c7". So "re-sync with upstream" is now a real option and worth deciding deliberately rather than drifting.

I ran a throwaway trial merge of upstream/master into our master to get hard numbers, then aborted it.

Divergence: 54 commits ours, 421 theirs since the 2026-06-15 split (it was 302 on 2026-08-07 — the gap is widening ~2 commits/day).

Trial merge: 49 conflicted files.

Area	Files	Note
tests	20
core src	16	tools/mod.rs alone has 112 conflict hunks
vscode-iris-agentic-dev/	6	modify/delete — we deleted it in PR #27, upstream still develops it
workflows	2	our 2025.3 image pin vs their 3-version matrix
Cargo.toml / lock / README / plugin.json	4

The reason it conflicts so badly is not drift — it is convergence. Upstream re-implemented the same fixes in their own shape: os_str_expr (4 files upstream), resolve_namespace (9), STORAGE_STRIP_BLOCKED (1). Both sides changed the same lines for the same reason with different code, which is the worst case for a textual merge and the easiest way to silently lose a behaviour — the 0.7.3 is_error compile envelope (#46), the did_you_mean guidance (#47), the image pin (#44), or the binary identity rename (#31).

There is also an identity collision: they are on 1.2.4, we are on 0.7.3, with a different binary name, a different release workflow (workshop VM assets), and a deliberately streamlined tool surface.

Recommendation: keep the fork, port features deliberately

Not a wholesale merge. The fork's value is exactly what a merge would flatten — a workshop-tuned error surface and a lean tool set. Concretely:

1. Port 056 interop-depth (this issue's top pick). Confirmed present upstream: iris_message_body, iris_business_rule_info, iris_production_diff, 14 files each. Port as our own change against 0.7.x, with tests, rather than by merging their history.
2. Re-read their versions of our fixes before porting anything near them — where their implementation is better than ours, adopt theirs on purpose.
3. Revisit wholesale re-convergence only if the fork stops being workshop-specific. At 421-and-growing, that decision gets more expensive every week, so it is worth making explicitly rather than by default.

[PYDuquesnoy]

056 interop-depth: done, shipped in v0.8.0-interop

This issue's top pick has landed (PR #55) — iris_message_body, iris_business_rule_info, iris_production_diff. Retitled to drop "056 first", since the list outlives that one item.

Ported as our own change against 0.7.x rather than by merging upstream history, per the re-sync assessment above. Adapted on four points rather than copied:

• every user string reaching ObjectScript goes through os_str_expr ([iris_lookup_transfer] action=import always fails with <SYNTAX> in the MCP's own generated routine (7/7) #6), and the two SQL lookups use bound parameters instead of interpolating a name into the statement;
• AnyParams → resolve_namespace + ensure_interop_namespace, so omitting namespace cannot silently land in USER ([interop] iris_execute ignores IRIS_NAMESPACE from the MCP server env and silently runs in USER #15);
• dataPolicy is a tool parameter defaulting to block, keeping the PHI gate without upstream's policy::gate subsystem;
• two defects fixed on top of the port, both found by running it against a live IRIS rather than by reading it: actual_size understated a truncated body (154-byte body read at max_bytes=40 reported 41), and action=list answered "no rules" on an instance whose Ens_Rule.RuleSet projection is empty even with a compiled Ens.Rule.Definition class — [mcp:error-surface] iris_test NO_TESTS_FOUND doesn't say what would have matched — 44 hits across 16/18 students #47's failure repeating, now a class-catalog fallback plus a RULE_NOT_PROJECTED code.

The interop profile went 20 → 23 tools.

What remains on this list

Nothing is committed to — this stays a candidate list, not a plan:

• Upstream is now at v1.2.4, 421 commits ahead of our split point (was 302 on 2026-08-07; the gap widens ~2/day). The measured trial-merge cost is in the assessment comment above: 49 conflicted files, 112 hunks in tools/mod.rs alone, and the conflicts come from convergence — they re-implemented our own fixes in their shape.
• Worth a look before the next port: upstream's output_schemas.rs (structured tool output shapes) and their policy::gate / dataPolicy plumbing, which we deliberately stubbed to a single tool parameter when porting 056.
• The decision this issue really tracks is not which feature to port next, but whether the fork stays deliberately lean and ports selectively, or re-converges with upstream. That gets more expensive every week it is left implicit.

[PYDuquesnoy]

Checklist audit against the tree at 3a6e38b (2026-08-26)

Re-checked each item against the code rather than against memory.

Landed since this issue was filed

• 056 interop-depth — done, and in the interop keep-list. iris_message_body, iris_business_rule_info and iris_production_diff are all present and all three are in INTEROP_TOOLS (that is what took the profile from 20 to 23). Ported with the simpler size-capped/redacted output this issue called for rather than upstream's PHI dataPolicy subsystem — and fe15dd6 fixed the EDI/VDoc redaction path afterwards ([mcp:gap] iris_message_body cannot read an EnsLib.HL7.Message body — the commonest body class on a health product #72).
• [~] 070 symbols_local overhaul — partially. Structured FormalSpec is in symbols_local.rs. BPL/DTL XData support and the 12 member kinds are not.

Still absent, verified by grep

item	state
064 iris_coverage	no such tool
065 iris_doc_search	no such tool
071 iris_execute %ctx session state	no %ctx carrier
057 sql-power (explain/count modes)	not present
positional edits (insert_lines / delete_lines)	not present in doc.rs
d3bc028 MCP ToolAnnotations	not present — no tool declares any

One of these is now worth more than it was

ToolAnnotations. This issue already calls it "cheap, protocol-level"; two things since have made it load-bearing rather than nice-to-have.

#104 established that the write gate is a real gate — a write-capable tool called against a Live instance is now refused at dispatch, not merely hidden from tools/list. But a client has no way to know in advance which tools those are: readOnlyHint / destructiveHint is precisely the metadata a confirmation UX gates on, and we ship none of it. Right now every tool looks alike to a client deciding whether to prompt.

#112 is the same shape one level over — we were not telling clients what our tools take; this is not telling them what our tools do. rmcp 1.6's #[tool] macro accepts annotations(read_only_hint = …, destructive_hint = …, idempotent_hint = …, open_world_hint = …), so it is a per-tool attribute and no new subsystem.

Worth noting it is not purely mechanical: iris_query looks read-only and is not — force: true bypasses the SELECT-only gate when write tools are enabled — so the classification needs a pass over each tool's actual reach, not a guess from its name.

Unchanged recommendation

The "poor fit" list still reads correctly; nothing since has changed the case for 072/073/074/051/044/061/059/063/052/053/055. Leaving them recorded as declined.

[PYDuquesnoy]

Port candidate: upstream PR #122 — block CodeMode=objectgenerator at write time

intersystems-community/iris-agentic-dev#122 (open, from @Nayrode) adds
check_compile_time_code_mode() in policy/code_edit_gate.rs and wires it into iris_doc
(put / insert / delete_lines) and iris_compile, refusing any class content declaring a method
with CodeMode = objectgenerator, expression or call. The stated threat: those run
ObjectScript at compile time under the identity of whoever triggers the compile, so an agent
with write access could plant a generator that fires on the next compile.

Where this fork already stands

Our executor does not use it. build_exec_class puts user code in RunUser() and runs it at
call time behind an Execute() SqlProc; build_exec_class_no_objectgenerator_uses_runuser
asserts the generated class contains no objectgenerator, and #122 in this repo adds a
tools/list guard so the description cannot drift back to claiming otherwise. Upstream reached the
same design independently (connection.rs:430). So the self-inflicted form of this risk is
already closed on both sides, and nothing in the port is needed for it.

The gate covers a different case: a caller asking iris_doc to write someone else's
generator class. We have no equivalent check.

The argument against porting it as-is

CodeMode = objectgenerator is ordinary IRIS, not an exploit primitive. %UnitTest.TestProduction
enforces its own PRODUCTION parameter with a method generator — CheckParameterPRODUCTION — which
is exactly the #5490: Error running generator for method 'CheckParameterPRODUCTION:...' that this
fork's own eval corpus produces 31 times. Method generators appear throughout %Library and
EnsLib. A blanket write-time block would stop an agent from writing legitimate ObjectScript, and
this fork's stated policy is dev-first with no friction: gate mutations against live instances,
never reads, and never ordinary development.

If it is ported, it should be a live-instance gate on the #114 model (refuse only where
connected_but_read_only(), overridable by IRIS_ALLOW_PROD=1), not an unconditional refusal —
and the error must name the method it objected to, or it becomes another Cannot open production.

Also open upstream, lower relevance

PR	author	note
#120	@mwaseem75	live-IRIS test for synthesized ^SKILLS skills — our ^SKILLS JSON handling already landed via #79
#124	@CraigRegester	[instance.*] fleet config when config_file is a toml path — we do not carry the fleet/pool feature
#126	@CraigRegester	Cursor IDE/CLI quick start — this fork already documents Cursor/Codex registration (#73, PR #77)

Recorded for the ledger, not proposed for action.

[Nayrode]

Hello, i just want to add some precisions:

• Blocking any writing on classes containing a "CodeMode = objectgenerator" was the simplest for me at the time since allowing it basically gives the agent the possibility to do everything. I think however that its a bit overkill and as you said, it also prevent legitimate writes
• The gate being used through a feature flag such as IRIS_ALLOW_PROD is a really good idea
• I was thinking about making it evolve, my current block prevent writing in the WHOLE class containing an objectgenerator, but there is some ways to soften it:

• Blocking if there is more that one addition of a "CodeMode = objectgenerator" method
• Comparing before/after the class edit and triggering a block if there is changes inside a "CodeMode = objectgenerator" method (need a proper parser)

[PYDuquesnoy]

Thanks @Nayrode — and congratulations on #122 landing upstream.

Your feature-flag suggestion is implemented and released here. Shipped in v0.9.1-interop (#137 / PR #138), and in every release since, including the current v0.12.0-interop:

• every iris_doc(mode=put) reports compile_time_methods: [names] for any class declaring a CodeMode = objectgenerator method, so the fact is always surfaced;
• IRIS_BLOCK_CODEGEN=1 (documented, default off) turns that into a refusal with error_code: COMPILE_TIME_CODE_BLOCKED.

So the default is report, and block is opt-in — which is the shape you called a good idea. Two ways we ended up narrower than #122, both for the reason you identified yourself:

Only objectgenerator, not expression or call. Those two inline at the call site and never run a generator at compile time, so refusing them costs legitimate writes and buys nothing against the threat as stated. objectgenerator is the one that executes under the identity of whoever triggers the next compile, which is the property that makes it interesting.

A blanket block breaks writing back IRIS-generated classes. This is the concrete legitimate-write case, and it bit us before we narrowed: a RecordMap's .Record class and SOAP web-client WSC.* classes are produced by IRIS itself and can carry a generator. Exporting one with iris_doc(mode=get) and writing it back is an ordinary round trip, and a whole-class refusal makes those classes permanently unwritable through the tool — with no way for the user to repair a class that is already in the namespace.

On your two softening ideas:

Counting additions (>1 generator) doesn't track the risk. One generator is exactly as dangerous as five — the threat is "arbitrary code runs at compile time under someone else's identity", and that is satisfied by the first one. A threshold mostly adds a number an attacker can stay under.

The before/after diff is the right idea, and "needs a proper parser" is only half true. Worth splitting: detection did not need a parser. We scan method signatures only, counting braces with string literals stripped out first — so a method body that happens to quote the phrase never trips it, and a body containing Quit "{{{" cannot strand the scan. That was enough to name every generator method in a class reliably. What genuinely does need parsing is your case: deciding whether the body of an existing generator changed. Also note the before-image is cheaper than it looks — the prior class content is one Atelier GET /doc/<name> away, so the diff does not require keeping state.

One last thing you may find useful, since it's the same trap from the other side: our own executor used to wrap submitted ObjectScript in a class that used CodeMode = objectgenerator, and we removed it — the wrapper now runs user code at call time in RunUser() instead, with a test asserting the generated class must never declare a generator. So we ran into the compile-time-execution problem as an author before meeting it as a gate.

Happy to compare notes if you take the diff approach further.