docs(divergences): the legacy intent toggle carries no target skill_id

appendix/divergences.md

@@ -533,7 +533,7 @@ a number of predecessor names. The mapping:
 | `padatious:register_entity` | `ovos.entity.register` | Entities are not Padatious-specific. |
 | `detach_intent` | `ovos.intent.deregister` | Identity now expressed as the structured triple, not the munged `skill_id:intent_name` string. |
 | `detach_skill` | `ovos.skill.deregister` | Predecessor handlers resolve the skill from `context`. A client that mirrors `ovos.skill.deregister` onto `detach_skill` therefore turns two shapes into a self-deregistration on the mirrored copy: a cross-skill deregistration (payload names another skill), which removes the source together with the target, and a malformed one (payload omits `skill_id`), which the spec handlers reject and the predecessor handlers act on. The cross-skill form of INTENT-4 §8.4 needs the mirror off (`emit_legacy=false` in ovos-bus-client); the malformed form is unsafe on a mirroring client rather than merely ignored. The mirror runs both ways through two flags: `emit_legacy` copies `ovos.skill.deregister` onto `detach_skill`, and `modernize` copies `detach_skill` onto `ovos.skill.deregister`. So a producer emitting `detach_skill` directly reaches the same consumers, and the source is removed whichever wire it uses. |
-| `mycroft.skill.enable_intent` / `mycroft.skill.disable_intent` | `ovos.intent.enable` / `ovos.intent.disable` | First-class topics under v1, with the prefix dropped. |
+| `mycroft.skill.enable_intent` / `mycroft.skill.disable_intent` | `ovos.intent.enable` / `ovos.intent.disable` | First-class topics under v1, with the prefix dropped. The legacy payload names only the intent and never a target `skill_id`, and the legacy payload has no field for the payload `skill_id` that INTENT-4 §3.2 requires. Current deployments act on a toggle in two ways. On the legacy topic, `ovos-workshop` sends the message to every skill, and each skill acts only when the named intent is one of its own; the target is the skill that receives the message, and nothing is logged. On the v1 topic, `ovos-spec-tools` copies only `intent_name` across the bridge, and `ovos-core` uses `context.skill_id` when the payload has no `skill_id` and logs the substitution at WARNING. The substitution only sets the manifest entry's `enabled` field (`ovos-core` `ovos_core/intent_services/manifest.py:270-275`). `ovos-adapt-pipeline-plugin` (`ovos_adapt/opm.py:96-118`) and `ovos-padatious-pipeline-plugin` (`ovos_padatious/opm.py:1088-1091`) act on the payload `skill_id` only, as §3.2 requires, so a bridged toggle changes the manifest's `enabled` field but not match candidacy. This substitution does not conform to §3.2 and is kept only while the legacy bridge exists. |
 | `mycroft.skills.loaded` | `ovos.skill.loaded` | Session-keyed, carries `capabilities` instead of a filesystem `path` and display `name`. `mycroft.skills.loading_failure` has no successor: a skill that did not load announces nothing. |
 | `skillmanager.list` / `mycroft.skills.list` | `ovos.skills.list` / `.list.response` | A `response` derivation with a `skills` array instead of a map keyed by skill id; entries carry `session_id`, `capabilities` and an intent count instead of `active`. |