@hobin/developer 0.1.11 → 0.1.12

package/README.md

@@ -7,7 +7,7 @@ Use it when a task may hide product rules, consequential cases, ownership,
 compatibility, structural timing, or pass-but-wrong verification. Developer:
 
 - turns consequential uncertainty into explicit questions;
-- routes Pi to one of ten focused judgment skills;
+- routes Pi to one of eleven focused judgment skills;
 - loads deeper references only when an observable trigger calls for them;
 - keeps implementation, unresolved questions, and verification evidence visible
   on the current session branch.
@@ -70,6 +70,19 @@ The tests pass after this cache rewrite.
 Check what they do not prove before calling it done.
 ```
 
+For a scope-bound existing-code diagnosis and improvement plan, ask for Doctor
+explicitly and name a path, flow, boundary, package, or subsystem when you can:
+
+```text
+Run a thorough Doctor review of the checkout request-to-persistence flow.
+Preserve current external behavior, consult every triggered Developer judgment,
+and produce a now/next/observe/leave-alone plan without modifying files.
+```
+
+When no useful scope is supplied, Doctor performs a cheap orientation pass and
+proposes one. It distinguishes requested, inspected, and claim scope rather than
+presenting a repository sample as an exhaustive review.
+
 ## Why Developer
 
 Ordinary coding requests often contain decisions that look like implementation
@@ -118,6 +131,7 @@ and the plausible judgment routes add no useful information.
 
 | Need | Developer helps Pi… |
 | --- | --- |
+| Diagnose existing code | Bound the review, preserve behavior, consult triggered judgments, and order justified improvements |
 | Clarify a feature | Separate meaning, constraints, examples, and blockers |
 | Model behavior | Enumerate cases, contracts, transitions, and guarantees |
 | Shape code | Expose data, interfaces, collaboration, state, and checks |
@@ -137,6 +151,7 @@ directly with `/skill:<name>`.
 
 | Skill | Helps decide |
 | --- | --- |
+| `doctor` | What a bounded existing-code scope must preserve, treat, observe, or leave alone |
 | `specify` | Product meaning, scope, invariants, and blockers |
 | `model` | Cases, contracts, transitions, guarantees, and checks |
 | `sketch` | Data, interfaces, collaboration, flow, state, and code shape |
@@ -152,6 +167,14 @@ Each skill produces an artifact suited to its question instead of defaulting to
 undifferentiated prose. Simple judgments remain compact when prose is genuinely
 clearer.
 
+Doctor is an explicit coordination workflow, not the default front door for
+ordinary tasks. It first makes a broad, shallow disposition of every available
+Developer judgment lens inside a declared scope. It then closes so each
+triggered question can run through its owning skill and all reference-policy
+routes supported by observable evidence. A final Doctor route synthesizes those
+owner judgments into a treatment plan; Doctor never reads sibling references or
+replaces their methods with one giant checklist.
+
 ## Commands
 
 | Command | Effect |

package/REFERENCE_ROUTING.md

@@ -198,6 +198,7 @@ separation behavior, and pass-but-wrong cases.
 
 | Skill | Policy routes | Shape |
 | --- | --- | --- |
+| `doctor` | none | scope, preservation baseline, universal lens disposition, consultation ledger, diagnosis, and treatment order; owner skills select and apply their own references |
 | `abstraction-review` | `candidate-contract-review`, `failed-candidate-check`, `candidate-calibration` | review, failure localization, or promise-based calibration; no shadow construction |
 | `model` | `condition-space`, `contract-replacement`, `relational-constraints`, `temporal-behavior`, `proof-obligation`, `solver-result-boundary`, `logic-query-semantics`, `planning-model` | one model artifact per uncertainty and stop condition |
 | `sketch` | `data-driven-design`, `data-shape-template`, `composition-by-wishes`, `earned-abstraction`, `generative-recursion`, `accumulator-invariant`, `evidence-preserving-boundary`, `design-levels`, `representation-barrier`, `closure-interface`, `process-resources`, `state-history-order`, `generic-dispatch`, `meaning-preserving-conversion`, `language-semantics`, `runtime-compilation`, `responsibility-collaboration`, `variation-role`, `type-transition`, `selection-creation` | one implementable design question per route, with route-local common kernels only where required |
@@ -209,6 +210,14 @@ separation behavior, and pass-but-wrong cases.
 | `visualize` | none | no packaged reference |
 | `adversarial-eval` | none | no packaged reference |
 
+Doctor does not aggregate sibling reference files into its own policy. In a
+thorough Doctor review it dispositions every available skill, closes the Doctor
+triage route, and hands each triggered question to its owner skill. The owner
+route then applies this contract to every independently triggered policy route
+and co-required reference set before Doctor synthesizes the recorded judgments.
+This makes all references eligible without loading unrelated methods or losing
+route-local provenance.
+
 The implementation execution profile under `extensions/references/` is selected
 by `execution_profile`, not by skill reference routing, and remains a separate
 contract.

package/extensions/compaction-language.ts

@@ -264,7 +264,7 @@ export function reconstructCompactionLanguage(
 }
 
 export function continuityMarkerText(tag: LanguageTag): string {
-	return `Post-compaction continuity: user-visible prose language=${tag}; explicit language requests win.`;
+	return `Silent control: do not acknowledge or quote this marker; continue the current task. User-visible prose language=${tag}; explicit user language requests win.`;
 }
 
 export function continuityContextMessage(
@@ -295,9 +295,11 @@ export function projectCompactionContinuity<T>(
 			state: CompactionLanguageState;
 	  }
 	| undefined {
-	if (!state.pending) return undefined;
+	if (!state.pending || state.pending.injected) return undefined;
+	// Pi presents custom messages to the model as user messages. Prepend this
+	// one-shot control so the retained task remains the latest request.
 	return {
-		messages: [...messages, continuityContextMessage(state.pending, timestamp)],
+		messages: [continuityContextMessage(state.pending, timestamp), ...messages],
 		state: markContinuityInjected(state),
 	};
 }

package/extensions/developer.ts

@@ -515,6 +515,9 @@ function protocolPrompt(
 		"Developer protocol is active.",
 		"- Use the default topology as a conditional backbone, not a rigid lifecycle: clarify meaning when needed -> model consequential cases -> sketch the first implementation surface for new behavior or signal the smallest structural movement in existing code -> execute one implementation step -> verify current claims.",
 		"- Adapt away from that topology when evidence makes a stage not applicable, but never jump directly from a resolved model to mutation: use sketch for feature implementation or signal for existing-code structural movement first.",
+		"- Route doctor only for an explicitly requested scope-bound diagnosis and improvement plan across several judgment kinds; it is not a mandatory prelude, pull-request review, environment check, or synonym for ordinary implementation.",
+		"- A thorough Doctor review is broad and shallow before it is narrow and deep: establish requested, inspected, and claim scope; disposition every other available Developer skill with evidence; close Doctor triage; route every triggered distinct consultation to its owning skill; let that owner select and apply every triggered policy route and co-required reference; then return to Doctor to synthesize diagnosis and treatment order. Doctor must not load sibling references or flatten their methods into one checklist.",
+		"- While Doctor consultations remain, keep one agent-owned before-completion synthesis question and update its remaining consultation evidence after each owner judgment; do not open one pending question per lens. Resolve it only in the final Doctor synthesis route.",
 		"- Route by the requested work product, not keywords: use sketch to create an original caller-facing interface, representation boundary, ownership map, or collaboration; use abstraction-review only when a concrete candidate surface already exists to keep/revise/split/reject/defer; use model first only when unresolved cases, rules, or policy can materially change that surface.",
 		`- Call ${ROUTE_TOOL} for exactly one concrete judgment or one green-to-green implementation movement.`,
 		"- Use target=implementation only when the next local movement, stable landing, narrow verification, and invariant handling are already justified; otherwise choose the focused skill whose scope fits the current question.",
@@ -1032,11 +1035,11 @@ export default async function developer(pi: ExtensionAPI) {
 		name: ROUTE_TOOL,
 		label: "Developer Route Question",
 		description:
-			"Route one concrete judgment or one green-to-green implementation movement. Route by work product: sketch creates an original design surface, abstraction-review judges an already-shaped candidate, and model settles unresolved conditions before design. Implementation must declare how invariant-bearing values are constructed without unchecked narrowing. Then use stable landings and verify before completion.",
+			"Route one concrete judgment or one green-to-green implementation movement. Route by work product: doctor coordinates an explicitly requested scope-bound existing-code diagnosis, sketch creates an original design surface, abstraction-review judges an already-shaped candidate, and model settles unresolved conditions before design. Implementation must declare how invariant-bearing values are constructed without unchecked narrowing. Then use stable landings and verify before completion.",
 		promptSnippet: "Choose how to handle one development question",
 		promptGuidelines: [
 			`Call ${ROUTE_TOOL} only when there is no active Developer route.`,
-			`Use ${ROUTE_TOOL} with the most focused skill supported by current evidence; choose sketch for an original interface or boundary, abstraction-review only for an already-shaped candidate, and model only for unresolved condition space. target=implementation requires one movement, one stable landing, one narrow verification, and a truthful invariant_handling declaration. Validation followed by an assertion is not an evidence-preserving boundary.`,
+			`Use ${ROUTE_TOOL} with the most focused skill supported by current evidence; choose doctor only for an explicit scope-bound existing-code diagnosis and improvement plan, choose sketch for an original interface or boundary, abstraction-review only for an already-shaped candidate, and model only for unresolved condition space. target=implementation requires one movement, one stable landing, one narrow verification, and a truthful invariant_handling declaration. Validation followed by an assertion is not an evidence-preserving boundary.`,
 			`When ${ROUTE_TOOL} follows an implementation judgment with another implementation route, cite the previous landing in known_evidence and record plausible skill routes in alternatives_considered instead of selecting implementation by momentum.`,
 			`After a resolved model, use sketch for first feature implementation framing or signal for existing-code structural movement before implementation mutation.`,
 		],
@@ -1261,6 +1264,11 @@ export default async function developer(pi: ExtensionAPI) {
 								`Reference contract: choose policy routes by observable trigger, use ${REFERENCE_TOOL} for every reference in each selected route's co-required set, and provide reference_basis for every loaded path; use reference_exemption only when no policy route applies.`,
 							]
 						: []),
+					...(skill && event.availableReferences.length === 0
+						? [
+								"Reference contract: this skill has no packaged references; omit both reference_basis and reference_exemption from its judgment.",
+							]
+						: []),
 					`Known evidence: ${event.knownEvidence.length > 0 ? event.knownEvidence.join(" | ") : "none"}`,
 					`Alternatives reconsidered: ${
 						event.consideredAlternatives.length > 0
@@ -1773,7 +1781,7 @@ export default async function developer(pi: ExtensionAPI) {
 		promptGuidelines: [
 			`Use ${JUDGMENT_TOOL} with the exact active Developer route ID.`,
 			`Use ${JUDGMENT_TOOL} result as Markdown and preserve the routed skill's inspectable tables, diagrams, matrices, timelines, and code blocks instead of reducing them to prose.`,
-			`For a resolved skill route with available references, use ${JUDGMENT_TOOL} reference_basis to connect each relied-on ${REFERENCE_TOOL} load to its trigger, applied rule, and resulting artifact, or use reference_exemption when no reference is relevant. Never provide both.`,
+			`For a resolved skill route with available references, use ${JUDGMENT_TOOL} reference_basis to connect each relied-on ${REFERENCE_TOOL} load to its trigger, applied rule, and resulting artifact, or use reference_exemption when no reference is relevant. Never provide both. For a skill with no packaged references, omit both fields.`,
 			`Use ${JUDGMENT_TOOL} open_questions with resolution_owner, gate, and resolution_criteria. User-owned gated questions require explanatory context before controls; for finite required decisions, add a choice-form response_spec with one field per decision. Use question_updates whenever current evidence settles or changes any existing pending question.`,
 			`Do not use ${JUDGMENT_TOOL} with resolved, not-applicable, or blocked status without at least one concrete basis.`,
 		],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hobin/developer",
-  "version": "0.1.11",
+  "version": "0.1.12",
   "description": "Branch-aware judgment routing, evidence gates, and focused development skills for Pi.",
   "type": "module",
   "keywords": ["pi-package", "pi", "developer", "skills"],

package/skills/doctor/SKILL.md

@@ -0,0 +1,284 @@
+---
+name: doctor
+description: "Diagnose a user-selected or explicitly bounded existing codebase scope and produce an evidence-backed improvement plan. Use for repository, package, directory, module, runtime-flow, boundary, or feature-slice review when behavior to preserve, invariant risk, structural pressure, evidence gaps, and justified now/next/later/leave-alone work must be assessed together. Not for pull-request diff review, environment setup checks, speculative cleanup, or automatic repair."
+---
+
+# Doctor
+
+Diagnose one bounded existing-code scope, consult the focused Developer judgments
+that its evidence actually triggers, and synthesize a treatment plan without
+turning age, style, or code smells into disease.
+
+## Core Question
+
+Within this explicit codebase scope, what must be preserved, what is at risk or
+obstructing change, and what should be treated now, prepared next, observed, or
+left alone?
+
+## Judgment Spine
+
+```text
+requested target and change horizon
+-> requested / inspected / claim scope
+-> behavior-preservation baseline
+-> broad, shallow disposition of every Developer judgment lens
+-> narrow, deep owner-skill consultations and triggered references
+-> evidence-backed mechanisms and treatment candidates
+-> treat-now | prepare-next | observe | leave-alone | needs-decision
+-> first concrete handoff
+```
+
+Doctor is broad in lens coverage and bounded in code coverage. It is not a fixed
+prelude for ordinary tasks.
+
+## Inputs
+
+- User-selected target, or evidence sufficient to propose one
+- Repository structure, entry points, callers, runtime flows, and public boundaries
+- Accepted behavior, tests, traces, incidents, schemas, and compatibility evidence
+- Current change pressure and intended horizon when available
+- Explicit review depth, lenses, exclusions, and evidence budget
+
+## Scope Contract
+
+Establish scope before diagnosis. Separate what was requested from what was
+actually inspected and from the area to which conclusions may apply.
+
+| Field | Required meaning |
+| --- | --- |
+| Requested target | What the user asked Doctor to review |
+| Selected scope | Path, symbol, runtime flow, boundary, feature slice, subsystem, or repository sample |
+| Included | Concrete paths, symbols, entry points, flows, or collaborators admitted |
+| Excluded | Nearby areas this review does not cover |
+| Depth | `local`, `collaborators`, `flow`, `subsystem`, or `repository-sample` |
+| Lenses | Requested concerns, or `balanced` when no concern dominates |
+| Evidence budget | Bounded files, history, commands, traces, or sampling rule |
+| Inspected scope | Evidence actually read or executed |
+| Claim boundary | The largest area current evidence can support conclusions about |
+
+If the user did not select a useful scope, perform only a cheap orientation pass:
+inspect manifests, subsystem boundaries, entry points, current failures or
+requests, recent change pressure, dependency hubs, and irreversible effects.
+Then propose the smallest valuable scope with evidence. Do not call an
+orientation sample a whole-repository diagnosis.
+
+A dependency outside scope may be inspected when the declared depth includes it.
+Otherwise present a scope-expansion candidate with the trigger, added surface,
+expected value, and cost. Never expand recursively by curiosity.
+
+## Review Mode
+
+Use `thorough-within-scope` unless the user explicitly asks for a faster pass.
+
+- `quick`: inspect the strongest observable risk and label all omitted lenses and
+  code surfaces as unreviewed;
+- `standard`: disposition every Developer lens, then deepen only the
+  highest-consequence or currently pressured consultations;
+- `thorough-within-scope`: disposition every available Developer lens, route
+  every triggered distinct consultation, inspect every policy-route trigger in
+  each selected owner skill, and apply every reference required by every
+  selected route.
+
+Exhaustiveness applies to judgment coverage inside the claim boundary, not to
+unbounded file traversal or unsupported whole-system claims.
+
+## Evidence Order
+
+Prefer evidence in this order while keeping disagreements visible:
+
+1. accepted user or product contract;
+2. observed externally meaningful behavior, production trace, incident, or
+   compatibility obligation;
+3. executable tests and fixtures whose observers match the claim;
+4. callers, state transitions, persisted representations, and effect order;
+5. implementation structure and static relationships;
+6. history, churn, coverage counts, complexity, and code smells as scope or
+   pressure clues only.
+
+A smell becomes a finding only when it is connected to a behavior, invariant,
+change cost, failure mode, evidence gap, or compatibility consequence. Age,
+language fashion, low coverage, duplication, or a long function alone does not
+justify treatment.
+
+## Preservation Baseline
+
+Before finding defects, record behavior and obligations that treatment must not
+break.
+
+| Behavior or contract | Owner / observers | Evidence | Confidence | Failure consequence |
+| --- | --- | --- | --- | --- |
+
+Cover relevant public APIs, critical user flows, persisted or legacy data,
+external input boundaries, state transitions, effect order, failure and retry
+behavior, and compatibility surfaces. Record `baseline evidence gap` when an
+important obligation has no distinguishing observer; do not silently treat it
+as absent.
+
+## Universal Lens Sweep
+
+In `standard` and `thorough-within-scope`, give every available Developer skill
+other than Doctor one disposition: `triggered`, `no-trigger`, `needs-evidence`,
+`out-of-scope`, or `blocked`. Each disposition requires concrete scope evidence.
+
+| Owner skill | Diagnostic question | Representative trigger |
+| --- | --- | --- |
+| `specify` | Is code deciding unresolved product meaning or scope? | docs, tests, callers, or defaults imply different product senses |
+| `model` | Are admitted, forbidden, absent, replacement, relational, or temporal conditions unsettled? | null/default/legacy combinations, invalid states, retries, ordering, solver or query semantics |
+| `sketch` | Is an implementable owner, boundary, representation, data flow, state flow, or collaboration missing? | unchecked narrowing, shotgun parsing, navigation leaks, mixed effects, repeated ownership decisions |
+| `signal` | Is observable structural movement present rather than mere similarity? | repeated change, closest parallel cases, model-code mismatch, boundary pressure |
+| `naming-judgment` | Do names preserve stable domain sense and expose consequential effects? | filler names, effect-hiding verbs, implementation-shaped names, sense collisions |
+| `abstraction-review` | Can callers safely rely on an already-shaped helper, API, interface, boundary, or workflow rule? | a concrete candidate makes unstable or leaking promises |
+| `schedule` | When does a stable concrete structural candidate belong? | current invariant pressure, nested work, delay cost, or lost reversibility |
+| `verify` | What do current checks prove, and what plausible wrong shape still passes? | green checks with observer, source, branch, construction-path, or effect-order gaps |
+| `adversarial-eval` | Does a consequential claim need escalating finite counterexamples? | ordinary checks can pass while security, data, compatibility, or workflow behavior is wrong |
+| `visualize` | Would a visual surface materially lower the cost of judging relationships? | state, ownership, flow, dependency, or ordering is hard to inspect in prose |
+
+Use this inspection surface:
+
+| Skill | Disposition | Scope evidence | Concrete consultation question or exemption |
+| --- | --- | --- | --- |
+
+`no-trigger` means observed evidence makes the compact question irrelevant here;
+it does not mean the entire codebase is healthy. `needs-evidence` names the
+smallest observation that could change the disposition.
+
+## Consultation Workflow
+
+Doctor does not impersonate all other skills and must not read sibling skill
+references inside a Doctor route.
+
+For every `triggered` disposition:
+
+1. write one concrete consultation question and its trigger evidence;
+2. close the Doctor triage route;
+3. route the question to its owning Developer skill;
+4. inspect every reference-policy route in that skill;
+5. select every route whose observable trigger answers a distinct unresolved
+   question;
+6. load and apply every co-required reference in the declared order;
+7. preserve the owner skill's artifact, stop, separation boundary, and
+   `reference_basis`;
+8. return to Doctor only after consultations resolve or become explicit gaps.
+
+Use dependency only when evidence requires it: unresolved meaning or condition
+space precedes a design that depends on it; `signal` precedes promotion of a
+new structural candidate; `sketch` creates an original surface;
+`abstraction-review` judges an existing surface; `schedule` requires a stable
+candidate; `verify` and `adversarial-eval` challenge the resulting claims. Do
+not run this as a mandatory phase sequence when a lens is `no-trigger`.
+
+When Developer protocol is active and consultations remain, keep one
+agent-owned `before-completion` Doctor synthesis question rather than opening one
+pending question per lens. Owner-skill judgments may resolve their narrow
+question while retaining that synthesis question with updated remaining work.
+The final Doctor route resolves it after integrating the consultation ledger.
+
+Use a consultation ledger:
+
+| Skill / policy route | Trigger evidence | Judgment artifact | Result | Residual gap |
+| --- | --- | --- | --- | --- |
+
+## Diagnosis
+
+Synthesize consultations into findings without erasing disagreement or evidence
+limits.
+
+| ID | Observation | Consequence | Mechanism | Evidence | Confidence | Affected scope | Owner judgment |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+A valid diagnosis names:
+
+- the observable behavior, invariant risk, change obstruction, or evidence gap;
+- the mechanism connecting code shape to that consequence;
+- supporting and contradicting evidence;
+- confidence and the exact claim boundary;
+- the smallest plausible falsifier;
+- a concrete candidate only when enough meaning and shape are stable.
+
+Do not merge independent findings merely because one treatment could touch the
+same files.
+
+## Treatment Plan
+
+Use ordinal decisions rather than pseudo-precise health scores.
+
+| Candidate | Diagnosis | Behavior to preserve | Guarantee gained | Current pressure | Dependencies / reversibility | Stable landing | Verifier | Decision |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+Decide:
+
+- `treat-now`: current correctness, security, data, compatibility, or invariant
+  risk justifies the smallest stable treatment;
+- `prepare-next`: the treatment is needed before the next related change to
+  avoid nested work or prevent a known recurrence;
+- `observe`: current pressure is insufficient; record an observable reopen
+  condition;
+- `leave-alone`: treatment is speculative, destroys useful freedom, or costs
+  more than the evidenced problem;
+- `needs-decision`: product, operational, or risk ownership cannot be inferred.
+
+Do not turn the treatment plan into a predetermined multi-step implementation
+queue. Provide one first handoff with its owner skill, preserved behavior,
+smallest stable landing, narrow verifier, and explicitly deferred work. Reobserve
+and reroute after that landing.
+
+## Output
+
+Lead with scope and the user's actual change or risk, not a health score. A
+resolved Doctor report contains:
+
+1. Doctor scope and actual coverage;
+2. preservation baseline;
+3. all required lens dispositions;
+4. consultation ledger with policy-route and reference provenance;
+5. diagnosis table;
+6. treatment plan;
+7. first concrete handoff and residual unknowns;
+8. an ASCII flow, ownership, state, or dependency map when relationships are
+   materially consequential.
+
+When used inside a larger task, return:
+
+```text
+Status: resolved | needs-evidence | not-applicable | blocked
+Result: scope-bound diagnosis and treatment order, or the consultation plan still required
+Basis: inspected code, behavior, callers, tests, traces, history, and owner-skill judgments
+Open questions: unresolved consultations, scope choices, product decisions, or none
+Artifacts: scope/coverage map, preservation baseline, lens matrix, consultation ledger, findings, treatment plan, and first handoff
+```
+
+Return only Doctor's scope, triage, or synthesis judgment for the current route;
+leave owner-skill consultation and implementation routing to the caller.
+
+## Completion
+
+A `thorough-within-scope` diagnosis is resolved only when:
+
+- requested, selected, inspected, and claim scopes are explicit;
+- every available non-Doctor skill has an evidence-backed disposition;
+- every triggered consultation is resolved or retained as an explicit gap;
+- every selected owner-skill policy route loaded and applied all required
+  references;
+- every finding has an observable consequence, mechanism, evidence, confidence,
+  scope, and falsifier;
+- every treatment preserves named behavior and has an owner and verifier;
+- every `treat-now` item has a smallest stable landing;
+- every `observe` item has a reopen condition;
+- intentionally unchanged areas are visible.
+
+Return `needs-evidence` after triage when owner-skill consultations, a baseline
+observer, or bounded repository evidence can settle the diagnosis. Return
+`blocked` when required product, operational, access, or risk ownership cannot
+be obtained. Return `not-applicable` when the request is a local diff review,
+environment check, already-shaped single judgment, or implementation task better
+owned directly by another skill.
+
+## Boundary
+
+Do not implement treatment, automatically repair files, recommend a rewrite
+because code is old, equate style or metrics with risk, invent product meaning,
+promote every duplication into an abstraction, flatten sibling skills into a
+checklist, load all references without triggers, or claim coverage beyond the
+inspected scope. Doctor owns scope, lens coverage, consultation planning,
+diagnostic synthesis, and treatment ordering; focused Developer skills own the
+actual judgments and their routed references.