Correct three authoring-doc claims flagged in tech review (#30)

[mraible]

Fixes #30.

A Fusion engineer's technical review flagged three factual errors that originated in the authoring skill documentation. This corrects them at the source, in both copies of yaml-schema.md (the authoring and workflows reference sets) plus the authoring SKILL.md.

version_constraint is not class-specific. The Common Pitfalls row and the discovery checklist framed it as a requirement of class-based actions. In reality nearly every action carries a version_constraint regardless of whether it declares a class, so it belongs on every action node. This changes doc framing only — validate.py behavior is unchanged.

System-level variables are not an exception. The variable-reference list showed trigger and workflow fields in the bare ${Trigger.X} form. Those fields live in the data namespace like any other field, so the list now uses the ${data['...']} form (including Trigger.CID, Workflow.Execution.ID, and Workflow.Definition.Name) and notes that the bare form is only for dedicated ID property fields, cross-referencing the existing interpolation-vs-dedicated-field guidance in trigger-types.md.

The action name: field is a relabelable display label. The schema comment said it must match the catalog name. It defaults to the catalog display name but can be renamed freely — next:/conditions resolve by the node key and action id, not by this label. The separate workflow-level name-stability guidance is unaffected and remains correct.

Verified offline: test-validate.sh (56/0), pytest (541 passed), markdownlint clean, and the authoring SKILL.md stays within the skill size budget.

[app-foundry-fusion-prodsec-142274]

Fusion Skills Eval Results

8/8 evals passed (100%) · model claude-opus-4-6 · commit dbaa5e0

Eval	Result	Prompt
contain-host-workflow	✅	details Create an on-demand Fusion workflow that contains a host. It takes a device ID and a note explaining why the host is being contained.
correlation-rule-hydration	✅	details I have a Next-Gen SIEM correlation rule that fires a detection, and I need to get the underlying event data into my Fusion workflow so I can act on it. Build a workflow triggered by that correlation-rule detection that hydrates it, pulls out the indicators, and emails me a summary.
detection-summary-email	✅	details Create a Fusion workflow that is triggered by a Next-Gen SIEM detection. Pull the full detection context with an event query, have Charlotte AI summarize it, and email the summary to my team.
gated-enrichment	✅	details Build a Fusion workflow triggered by a Next-Gen SIEM detection. Pull the detection details with an event query, then look up indicators in VirusTotal, but only the ones actually present on the detection. Cover the domain, the IP, and the file hash. Email me a summary.
negative-impossible-api	✅	details Build a Fusion workflow that enriches a detection's IP address by calling the FooBarBaz threat-intel API at https://api.foobarbaz-nonexistent.example.com, using their v3 real-time reputation endpoint. If you cannot verify this API exists or find its documentation, build only a minimal placeholder and tell me what you could not confirm.
negative-overengineering	✅	details Build a simple on-demand Fusion workflow with a single action that writes the message "hello world" to the workflow log. Nothing else.
severity-routing-workflow	✅	details Create a workflow triggered by an EPP detection alert. If the detection severity is Critical or High, contain the host immediately and send a Slack notification. If severity is Medium, just send the Slack notification without containment. Low severity detections should be logged but take no action.
signal-trigger-event	✅	details Write a Fusion workflow that is triggered by a Next-Gen SIEM detection and simply writes the detection ID to the log repo. Keep it minimal: one trigger, one action.

Suggested improvements (7)

• contain-host-workflow — Missing version_constraint: ~0 on the ContainDevice action (Contain device has no class/semantic_version and should carry ~0).
• correlation-rule-hydration — Read extracted indicators (IPs, hostnames, usernames) from the Event Query results array (e.g. ${data['HydrateEventQuery.results'][0].LocalAddressIP4}) instead of from Trigger.Detection.NGSIEM.* payload fields, to fully leverage the hydration query output.
• detection-summary-email — The data_to_include field uses bare ${EventQueryDetectionContext.raw_results} for prior-action output which should be ${data['EventQueryDetectionContext.raw_results']} per data-reference conventions for non-trigger action outputs.
• gated-enrichment — VTFileHashLookup uses a single-segment hex ID with version_constraint 1 while the other VirusTotal plugin actions use compound hexhex IDs with ~0, suggesting inconsistency in discovery method or action type.
• negative-impossible-api — Remove or blank out the _cs_inline_output_schema and downstream field references, replacing them with clearly-labeled unknowns or instructing the user to fill them in after verifying the real API docs.
• negative-overengineering — Remove the _fields array since a simple hello world message needs only the custom_json payload
• severity-routing-workflow — Use the print-data action for the low-severity logging branch as specified, and verify that the Slack action ID is a compound plugin format (hex_hex) as expected for Store plugin actions.

_{On-demand eval run. Re-runs update this comment in place.}