Exempt active glossary vocabulary from stage protection

docs/roadmap/glossary-stages.md

@@ -56,9 +56,10 @@ the root settings or the defaults seen by later stages.
 
 In this example, the first glossary stage uses `party.yml` as its correction
 input, the second uses `spells.yml`, and grammar inherits both glossary inputs.
-All three stages inherit protection from both files through the root default
-described below. Transcript changes carry forward between stages; configuration
-overrides do not. Each consumer receives the appropriate selection from the
+All three stages inherit a protection selection containing both files through
+the root default described below. Glossary stages then exempt their active
+vocabulary from protection. Transcript changes carry forward between stages;
+configuration overrides do not. Each consumer receives the appropriate selection from the
 stage's effective settings, keeping correction/context inputs and protection
 inputs distinct.
 
@@ -129,28 +130,48 @@ Resolve these settings in this order:
 3. Independently inherit the effective root `glossaries` and `protected_terms`
    into each stage wherever that stage omits the corresponding setting. A stage
    override replaces only its own selected list.
+4. For a glossary module stage, construct its effective protected vocabulary by
+   subtracting its active glossary terms from its selected protected terms.
+   Non-glossary stages use their selected protection vocabulary without this
+   subtraction.
 
 Protection therefore defaults at the root before stage inheritance. It does not
 fall back to a focused stage's glossary list. In the example above, no operator
 protection configuration is needed:
 
-| Stage | Glossary input | Protected vocabulary |
-| --- | --- | --- |
-| Party glossary pass | Party | Party + spells |
-| Spell glossary pass | Spells | Party + spells |
-| Grammar | Party + spells | Party + spells |
+| Stage | Glossary input | Protection selection | Effective protected vocabulary |
+| --- | --- | --- | --- |
+| Party glossary pass | Party | Party + spells | Spells |
+| Spell glossary pass | Spells | Party + spells | Party |
+| Grammar | Party + spells | Party + spells | Party + spells |
+
+The table assumes distinct party and spell vocabulary. The subtraction applies
+after resolving both stage selections, including explicit protection overrides.
+It operates on recognized terms using the protection matcher's rules, including
+names, aliases, and supported plural forms, rather than subtracting file paths.
+Terms shared across files therefore participate in the same operation; shared
+spellings associated with different identities remain part of the overlap
+decision below.
+
+Keep the configured protection file list intact and construct the reduced
+vocabulary separately for that stage. Do not mutate root settings, loaded
+glossary entries, or another stage's protection. A glossary stage selecting all
+of its protected vocabulary as active input has no glossary-derived protection
+from those terms; its other validators still assess proposed corrections.
 
 A stage can supply a narrower or different `protected_terms` list. Explicit
 `protected_terms: []` disables glossary-derived protection for that stage without
 clearing its correction/context inputs or disabling other validators. Explicit
-`glossaries: []` clears correction/context inputs without changing protection.
+`glossaries: []` clears correction/context inputs without changing the protection
+selection.
 A glossary-correction stage requires a nonempty effective glossary selection;
 other stages may operate without glossary context where supported. A glossary
 selected only by a stage is not automatically added to root protection.
 
-Protection must retain module-appropriate allowances for legitimate glossary
-corrections and spoken-word cleanup. Carry both selections through execution and
-validation rather than passing a single combined glossary to every consumer.
+Use the active-term exemption for glossary correction and retain the existing
+module-appropriate allowance for spoken-word cleanup. Carry both selections
+through execution and validation rather than passing a single combined glossary
+to every consumer.
 Combined-entry conflicts and overlapping protected identities remain open below.
 
 ### Validation-Profile Fallback — Resolved
@@ -331,8 +352,8 @@ that each stage receives its intended correction and protection selections,
 that overrides do not leak into other stages, and that the second stage sees
 the first stage's accepted transcript changes. Verify meaningful errors for
 invalid selections or inputs, and retain the selected domain validation and
-partial-success behavior. Exact
-test cases follow the design; live provider calls are unnecessary.
+partial-success behavior. Exact test cases follow the design; live provider
+calls are unnecessary.
 
 Verify root fallback, per-stage override isolation, and explicit-value presence
 for the selected stage settings. Include the grammar stage after the overridden
@@ -361,6 +382,13 @@ Cover root protection defaulting after CLI assignment, explicit root protection
 surviving glossary overrides, and recorded root-to-stage protection dependencies.
 Verify module-appropriate protection using terminology from both files, including
 legitimate corrections and cleanup; test the selected overlap/conflict behavior.
+For glossary stages, verify that active terms are exempt while remaining selected
+terms stay protected, including when protection was explicitly configured.
+Cover names, aliases, supported plurals, and vocabulary shared across files.
+Verify the all-active case produces an empty effective protected vocabulary
+without disabling other validators. Confirm that a later non-glossary stage
+still protects its full selection and that inspection distinguishes configured
+protection inputs from the glossary stage's effective protected vocabulary.
 Confirm that the durable policy, configuration contracts, and contributor
 guidance are in place before declaring this feature complete.
 
@@ -387,9 +415,10 @@ for no-main-file operation as well.
 **Recommendation:** preserve declared file and entry order, coalesce identical
 entries, and diagnose conflicting definitions rather than silently choosing by
 file order. Define identity handling for overlapping names, aliases, and plurals
-across the correction and protection selections, including legitimate glossary
-corrections. This keeps protection explainable but requires distinguishing true
-conflicts from harmless repetition or legitimate shared spellings.
+across the correction and protection selections, including how the active-term
+exemption handles a shared spelling associated with different identities. This
+keeps protection explainable but requires distinguishing true conflicts from
+harmless repetition or legitimate shared spellings.
 
 **Alternative:** use documented ordered precedence for conflicting entries. This
 supports intentional local overrides and is straightforward to apply, but can