Workflow refactor

.agents/skills/ub-governance/SKILL.md

@@ -7,8 +7,8 @@ description : >-
    when the task involves governance modes, test-signal review, evidence
    levels, or decision-memory boundaries; or when they ask whether work needs
    governance escalation. Do not use it for workflow planning, framework
-   implementation, or this repository's repo-maintenance catalog, path, and
-   skill-integrity checks.
+   implementation, or the host repository's own maintenance catalog, path,
+   and skill-integrity checks.
 context     : fork
 metadata    :
    desktop-portfolio-help-topics       : "overview,evidence,testing,repository,core,glossary,combos,invoke"
@@ -152,7 +152,8 @@ If a trigger is not active, do not read the reference just because it exists.
    Use `testing mode`, apply the test-signal model, and treat likely `TG002`
    findings as blocking only when the suite is asserting interaction without
    externally observable outcome.
-3. `Show me the repo-maintenance checks for README, AGENTS, and skill schema.`
+3. `Show me the host repository's maintenance checks for README, AGENTS,
+   and skill schema.`
    Do not route that through governance. Those checks belong to the
    host repository's own maintenance/check surface.
 

.agents/skills/ub-governance/references/decision-memory-and-claims.md

@@ -58,7 +58,11 @@ For Level 1 workflow-backed work:
    alternative was rejected, and what was explicitly deferred
 3. sprint `evidence/` is the default evidence location for sprint-scoped proof
    and should stay closer to the work than initiative-root summaries
-4. initiative-root `research/` and `exceptions/` are supporting surfaces, not
+4. workflow research claim registries, when used by a host overlay, are
+   Level 1 workflow-native context records unless the decision is escalated to
+   repository-level governance or a blocking governance result depends on claim
+   confidence
+5. initiative-root `research/` and `exceptions/` are supporting surfaces, not
    generic dumping grounds
 
 Ordinary initiative example:
@@ -110,11 +114,13 @@ Typical triggers:
 3. an exception or waiver remains acceptable only because supporting claims
    stay verified or explicitly bounded
 
-Do not require claim-register work by default for:
+Do not require governance claim-register work by default for:
 
 1. ordinary Level 1 workflow-backed initiative records
-2. descriptive examples or non-blocking explanatory prose
-3. decisions that can be justified directly from deterministic artifacts
+2. workflow-native research claim registries that only route discovery context
+   and do not support a blocking governance result
+3. descriptive examples or non-blocking explanatory prose
+4. decisions that can be justified directly from deterministic artifacts
    without claim confidence
 
 High-risk-governance example:

.agents/skills/ub-governance/references/governance-commands.md

@@ -33,7 +33,7 @@ Operator intent:
    and bounded initiative `exceptions/` instead of invoking ADR machinery by
    default.
 4. Repository-catalog, package-metadata, and skill-surface integrity scripts
-   are repo-maintenance tooling, not default governance commands.
+   are host-repository maintenance tooling, not default governance commands.
 
 Host-repository wrappers:
 
@@ -42,10 +42,10 @@ Host-repository wrappers:
 2. A host repository may expose a governance-regression wrapper through its own
    task runner.
 
-Repo-local maintenance note:
+Host-repository maintenance note:
 
-1. Repo-maintenance wrappers belong to the host repository's own documented
-   maintenance/check surface.
+1. Host-repository maintenance wrappers belong to the host repository's own
+   documented maintenance/check surface.
 2. That surface is intentionally separate from the distributable governance
    command set carried by this skill.
 

.agents/skills/ub-python/SKILL.md

@@ -128,6 +128,11 @@ Python lint config of its own.
 - Use `Protocol`, `Self`, `override`, `TypeGuard`, `TypeIs`, `Required`, `NotRequired`, `ReadOnly`, `TypeAliasType`, and `assert_never` when they improve correctness and refactor safety.
 - Do not invent custom typing compatibility shims when `typing_extensions` already provides the migration path.
 - Keep `Any` contained to boundaries and document why when unavoidable.
+- In strict public or SDK-facing code, avoid ambiguous constructor overloads
+  such as `dict(mapping)` when the source type is a recursive alias or broad
+  `Mapping[str, JsonValue]`; prefer typed copy helpers, `{**mapping}`, or
+  explicit payload builders so Pyright/Pylance can prove the exact return
+  shape.
 
 ### Data Modeling and Validation
 

.agents/skills/ub-python/references/python-standards.md

@@ -56,6 +56,27 @@ specific host repository.
 - Prefer forward-compatible helpers and backports where they preserve the
   current repo floor while reducing future migration work, but do not emit
   syntax that the active runtime cannot parse.
+- Avoid ambiguous overloaded constructors in strict public API code when the
+  source type is a recursive alias, broad mapping, or JSON-like boundary type.
+  `dict(mapping)` is valid Python, but type checkers may choose an overload
+  that widens or rejects recursive shapes such as `Mapping[str, JsonValue]`.
+  Prefer an explicit typed helper, `{**mapping}`, or a purpose-built payload
+  builder when exact `dict[str, T]` output matters.
+
+Example:
+
+```python
+type JsonValue = None | bool | int | float | str | list["JsonValue"] | dict[str, "JsonValue"]
+type JsonObject = Mapping[str, JsonValue]
+
+
+def json_object_copy(value: JsonObject) -> dict[str, JsonValue]:
+    return {**value}
+```
+
+This is a strict-typing practice, not a Python runtime-version requirement:
+`dict(mapping)` remains legal, but explicit copy helpers reduce Pyright,
+Pylance, and basedpyright overload drift in SDK-facing code.
 
 ## 4. Data Modeling and Boundary Validation
 

.agents/skills/ub-quality/references/freshness-portability.md

@@ -83,3 +83,37 @@ Rules:
 1. do not create a new blocker just because a skill is marked high-volatility
 2. use freshness markers to prioritize review, not to halt unrelated work
 3. tighten freshness only after the repository explicitly chooses stronger enforcement
+
+## Parallel Research Delegation
+
+When freshness, portability, donor comparison, official documentation review,
+or analogous-system research has two or more independent read-heavy slices,
+prefer explicit parallel delegation when the current agent runtime supports it.
+
+Portable trigger:
+
+1. each slice can be investigated without depending on another slice's result
+2. the expected output is distilled evidence, not implementation
+3. the sources or allowed paths can be bounded up front
+4. the parent thread can verify anchors and reconcile conflicts
+
+Delegation contract:
+
+1. assign one subagent, background thread, or equivalent worker per slice
+2. give each worker a bounded read-only task, allowed sources or paths, and
+   no-edit constraints
+3. ask workers to return distilled findings with fact, inference, source,
+   implication, and rejected pattern when that shape fits the research
+4. wait for all requested workers before consolidating
+5. keep the parent agent accountable for source verification, conflict
+   reconciliation, and final recommendation
+
+Do not delegate when the task is single-threaded, the current runtime lacks a
+safe subagent or background-thread surface, authorization boundaries are
+unclear, or parallel work would mostly duplicate context. Use narrow
+sequential passes instead.
+
+Do not use recursive fan-out unless the operator explicitly asks for it and the
+runtime supports bounded recursion. For proprietary donors, use only authorized
+paths, public docs, public license or README material, and observed behavior
+the operator is allowed to inspect.