ultra-builder-pro-cli 5.0.0 → 6.0.0

package/skills/ultra-research/SKILL.md

@@ -1,167 +0,0 @@
----
-name: ultra-research
-description: Turn a raw Project Brief or scoped evidence gap into an accepted North Star, domain language, cited product and architecture specifications, and a hash-bound synthesis. Use after initialization, for brownfield baselining, or inside an active Change whose consequential claims are not yet evidenced.
----
-
-# Mature a project outline into an evidence-backed baseline
-
-Research is the first semantic writer of North Star v2 and owns the first accepted
-baseline plus later evidence-backed corrections. Web
-search is one evidence source, not the workflow: repository files, Git, tests, runtime,
-maintained documentation, owner decisions, and current primary sources all count.
-
-## Route modes
-
-| Mode | Entry | Observable exit | Next |
-|---|---|---|---|
-| `baseline` | Explicit owner invocation with a usable Project Brief and no accepted baseline for the boundary | Selected reports, synthesis, specifications, vocabulary, and accepted North Star are read back; unknowns and omissions remain explicit | Recommend `ultra-change` in `intake` mode for the next bounded request |
-| `change-scoped` | Explicit invocation or a valid Execution Grant for one active Change's recorded Research Disposition | The named exit evidence exists and the selected canonical sections are refreshed without changing Change acceptance | Return to the same `ultra-change` in `reconcile` mode |
-
-Follow `../ultra-status/references/route-contract.md`. At entry, name the mode, entry
-question, selected coverage, observable stop condition, and return route. Refresh the
-Route Card at each material checkpoint, pause, and exit; lens counts are navigation, not
-proof that Research is semantically complete.
-
-## Before you start
-
-1. Resolve `baseline` or `change-scoped` from the artifacts and invocation. A
-   model-selected run is valid only for `change-scoped` mode under the live execution
-   grant in `../ultra-change/references/execution-grant.md` — a current session-local
-   activation or a stably verified durable work-package grant covering the same Change;
-   without it, stop and recommend explicit invocation. Baseline adoption is always an
-   explicit-entry mode.
-2. Resolve at most one active `change_id`, then read `.ultra/tasks.json` plus the
-   `context_file` and `## Resume Note` of unfinished tasks whose `change_id` matches it,
-   if any. Archived or abandoned unfinished rows are history, not the current frontier.
-3. Read `.ultra/project-brief.md`. For a legacy project without it, treat the exact
-   `.ultra/north-star.md` `## One-line` as raw intake until a brief is preserved.
-4. Read existing `.ultra/north-star.md`, specifications, `CONTEXT.md`, relevant
-   `.ultra/decisions/`, active Change intent, evidence, Git state, and maintained docs.
-   Run `node <ultra-research-skill-dir>/scripts/validate_north_star.cjs
-   .ultra/north-star.md`; this entry captures one bounded regular non-symlink snapshot
-   and returns a typed repair diagnostic instead of following, blocking on, or validating
-   a changing path. Treat `unresearched` as an empty destination and `legacy_unadopted`
-   as preserved intake for explicit adoption, not accepted v2 truth.
-
-## Definition of done
-
-- Every selected lens has a cited `.ultra/research/<run-id>/<area>.md` report and its
-  canonical specification section contains the current conclusion and North Star relation.
-- The accepted North Star, shared vocabulary, product baseline, and architecture
-  baseline are sufficient for the current planning boundary; unknowns stay explicit.
-- The North Star follows `references/north-star-v2.md`; all `FP-*`, `NS-*`, and `HC-*`
-  definitions and references pass the structural validator without making that result
-  a semantic verdict.
-- `99-synthesis.md` names what was promoted, overturned, deferred, or left blocking.
-- `.ultra/specs/research-distillate.md` stores the Git blob hash of each specification
-  it summarizes. A mismatch makes the distillate stale, never authoritative.
-
-## Find the path before collecting evidence
-
-When coverage spans several lenses or the path itself is unclear, read
-`references/wayfinding.md` and write `.ultra/research/<run-id>/brief.md`. Skip that file
-for one already-bounded evidence question. Wayfinding selects the smallest useful
-coverage; it does not create workflow state or another semantic authority.
-
-The derived brief records the entry question, selected lenses, deliberate omissions,
-dependencies, source plan, material checkpoints, observable stop condition, and return
-route. Read it on a fresh session instead of restarting completed evidence collection.
-
-Map the brief and unresolved specification sections to seventeen focused evidence
-lenses. Show the proposed coverage once. Pause only when it expands an accepted boundary
-or creates another material checkpoint; a covering Change Research Disposition does not
-need a duplicate confirmation. Load one reference at a time; the parent holds the
-question map, not every step prompt.
-
-The first six lenses have real semantic dependencies:
-
-- `00-problem-validation` runs before `01-opportunity-discovery` because an opportunity must trace to a problem.
-- `02-market-assessment` and `03-alternatives` are conditional lenses and may run in parallel once the boundary is known.
-- `04-product-strategy` is the first owner checkpoint and consumes the relevant conclusions from `00` through `03`.
-- `05-assumptions-validation` extracts load-bearing assumptions from `00` through `04` after the strategy decision.
-
-The later groups turn that premise into product behavior (`10` through `22`), then an
-architecture and operating baseline (`30` through `41`). The three owner checkpoints
-remain `04-product-strategy`, `21-features-scope`, and `99-synthesis`.
-At each checkpoint, use `../ultra-think/SKILL.md` for an adversarial challenge of the
-working candidate before asking the owner to accept direction, scope, or synthesis.
-
-Only areas with satisfied inputs may fan out through native bounded subagents. Never
-parallelize a lens whose question depends on an unresolved earlier conclusion.
-
-## Investigate, ask, and decide
-
-For each selected lens:
-
-1. Inspect reachable facts before asking. Search current primary sources when a claim
-   depends on current external reality.
-2. Separate Observed, Verified, Decided, Inference, and Unknown; cite external claims.
-   Record `north_star_effect: supports | refines | contradicts | independent` and
-   `north_star_claim: <the evidenced causal relation>` in the area report.
-3. Follow `../ultra-grilling/SKILL.md` when a required owner field is missing. The lens
-   supplies what to ask; Grilling supplies the one-question interaction loop.
-4. Follow `../ultra-think/SKILL.md` for one consequential trade-off, not for mapping the
-   whole research frontier.
-5. Follow `../ultra-domain-modeling/SKILL.md` when evidence settles a shared term. The
-   first such term creates `CONTEXT.md`; later calls sharpen it.
-6. Write the area report, then replace the mapped specification section instead of
-   appending a second version. Git retains history.
-
-For scoped Research inside an active Change, answer only its recorded `Research
-Disposition` question and produce the named exit evidence. Research writes reports and
-the mapped canonical baseline sections; it does not silently rewrite Change acceptance.
-Return the evidence paths so `ultra-change` can reconcile the accepted intent before
-planning when that contract must change. The scoped run's return route is always the
-same stable Change, even when the evidence supports the original intent unchanged.
-
-If web access is unavailable, record `[UNVERIFIED: no web access]` and continue with
-other evidence. Missing tooling lowers confidence; it does not manufacture a blocker.
-
-## Synthesize the accepted baseline
-
-`04-product-strategy` proposes problem reality and falsifiable first-principle
-propositions. `22-success-metrics` determines whether a
-single North Star metric is justified or whether an observable outcome plus guardrails
-is more honest. Follow `references/north-star-v2.md`: validate a mutable candidate while
-the last accepted revision remains current, show the owner the semantic delta and
-unresolved contradictions, and preserve one stable `.ultra/decisions/<id>.md` acceptance
-record with the owner's exact words, conversation scope, the model's responsibility for
-final wording, and no invented timestamp or inheritance by a future revision. Only after
-the owner accepts the candidate, atomically replace `.ultra/north-star.md`, then update the three
-specifications, domain language, qualifying decisions, and distillate for the first
-baseline. A scoped Research run updates only its mapped specification sections and then
-refreshes the distillate's three source hashes.
-
-When an accepted revision supersedes another, preserve prior evidence and report every
-active Change whose recorded revision or digest differs as a stale observation requiring
-Change reconciliation. Supersession never deletes evidence, rewrites a Change silently,
-or grants execution.
-
-Load `references/99-synthesis.md` only after selected reports exist. Read every promoted
-file back, verify trace anchors and source hashes, and report exact unresolved gaps.
-For `baseline`, recommend `ultra-change/intake`; for `change-scoped`, return the named
-evidence to `ultra-change/reconcile`. Invoke neither unless the latter continuation is
-covered by the same valid Execution Grant; when it is covered, show the transition Route
-Card first and let Change re-verify its own mode and grant.
-
-## When the owner decides
-
-The owner chooses coverage, resolves the three checkpoints, accepts a North Star and
-material deferrals, and authorizes any REDUCTION. The model establishes evidence facts,
-selects methods, and updates accepted files inside that frame.
-
-## References
-
-- `references/wayfinding.md` — read only for multi-lens or unclear research paths.
-- `references/00-problem-validation.md` through `references/05-assumptions-validation.md`
-  — product premise and strategy; load only a selected lens.
-- `references/10-user-personas.md` through `references/22-success-metrics.md` — actors,
-  behavior, scope, and measurements.
-- `references/30-architecture-context.md` through `references/41-quality-risks.md` —
-  system boundary, implementation evidence, operations, and risk.
-- `references/99-synthesis.md` — load last, after selected reports exist.
-- `references/north-star-v2.md` — exact semantic structure, adoption, validation, and
-  supersession contract.
-- `../ultra-change/references/execution-grant.md` — read only for grant-activated continuation.
-- `../ultra-status/references/route-contract.md` — owner-visible route, checkpoint, and recovery output.
-- `../ultra-think/references/autonomy-boundary.md` — read before reducing authority.

package/skills/ultra-research/references/00-problem-validation.md

@@ -1,36 +0,0 @@
-# Problem validation
-
-Use for workflow step `00-problem-validation`.
-
-## Objective
-
-Establish the problem, affected actor, current workaround, consequence, and available
-demand evidence. In brownfield adoption, describe the behavior the current system
-already serves before discussing future intent.
-
-## Evidence
-
-- Inspect existing product documents, user-facing entry points, support evidence, and
-  runtime behavior before asking the owner for facts already present.
-- Treat an owner statement as a decision or claim, not as observed user evidence.
-- Record absent evidence as `Unknown`; do not invent demand, urgency, or a target user.
-- Use external research only when a consequential claim depends on current facts.
-
-## Record
-
-Update `discovery.md` with `Observed`, `Verified`, `Decided`, and `Unknown` entries for:
-
-- problem and affected actor;
-- current workaround and consequence;
-- demand or usage evidence;
-- the narrowest owner-approved problem boundary;
-- unresolved validation needs.
-
-Link the updated specification anchor from the bounded area report written for this
-research run. A missing load-bearing fact becomes a blocker or baseline gap, not a
-guessed answer.
-
-## Report trace
-
-In the area report, record `actor`, `current_workaround`, `consequence`, and
-`evidence_status`, then link the updated specification anchor.

package/skills/ultra-research/references/01-opportunity-discovery.md

@@ -1,33 +0,0 @@
-# Opportunity discovery
-
-Use for workflow step `01-opportunity-discovery`.
-
-## Objective
-
-Connect the validated problem to desired outcomes and evidence-backed opportunities.
-Describe opportunities from the actor's perspective rather than as a feature list.
-
-## Evidence
-
-- Derive current outcomes from observed workflows, existing behavior, interviews, or
-  owner decisions.
-- Preserve causal links between a problem, an unmet outcome, and its evidence.
-- Do not force rankings, solution brainstorming, or a fixed number of opportunities.
-- Record opportunities that lack evidence as unknown or future research.
-
-## Record
-
-Update `discovery.md` with:
-
-- desired outcomes and their evidence;
-- opportunity statements and affected actors;
-- constraints or dependencies;
-- owner-decided priority when one exists;
-- rejected or deferred opportunities only when that decision is durable.
-
-Complete the step with the evidence used and the updated output path.
-
-## Report trace
-
-In the area report, record `actor`, `desired_outcome`, and `evidence_status`. Link the
-conclusion to its problem anchor when that relation is established.

package/skills/ultra-research/references/02-market-assessment.md

@@ -1,31 +0,0 @@
-# Market assessment
-
-Use for workflow step `02-market-assessment`.
-
-## Objective
-
-Record only market facts that materially affect product scope, economics, regulation,
-or delivery. For an internal tool or a brownfield system with no market decision, state
-that boundary and retain the evidence supporting it.
-
-## Evidence
-
-- Prefer current primary sources, filings, official statistics, and directly observed
-  commercial data.
-- Preserve source date, geography, segment definition, and calculation assumptions.
-- Do not manufacture TAM, growth rates, pricing, or false numeric precision.
-- Separate externally verified facts from owner targets and estimates.
-
-## Record
-
-Update `discovery.md` with relevant segment boundaries, commercial or operational
-constraints, source-backed measurements, assumptions, and unknowns. Include a sizing
-model only when the decision genuinely depends on one and the inputs are defensible.
-
-Link source references and the updated specification anchor from the bounded area
-report written for this research run.
-
-## Report trace
-
-In the area report, record `constraint`, `decision_impact`, and `freshness`, then link
-the updated discovery anchor.

package/skills/ultra-research/references/03-alternatives.md

@@ -1,31 +0,0 @@
-# Alternatives
-
-Use for workflow step `03-alternatives`.
-
-## Objective
-
-Identify the alternatives actors actually use and the consequences for strategy.
-Alternatives include direct products, adjacent tools, manual workflows, or doing
-nothing; a competitor-only frame is too narrow.
-
-## Evidence
-
-- Use current product documentation, pricing, repositories, filings, or observed user
-  workflows.
-- Evaluate only criteria that change the decision at hand.
-- Do not create a ceremonial matrix, fixed alternative count, or unsupported claim of
-  superiority.
-- Distinguish a verified capability from marketing language and inference.
-
-## Record
-
-Update `discovery.md` with relevant alternatives, evidence, meaningful differences,
-switching constraints, and durable strategy implications. Record an unknown when a
-credible alternative cannot be verified.
-
-Complete the step with evidence references and the updated output path.
-
-## Report trace
-
-In the area report, record `category`, `switching_constraint`, and
-`strategy_implication`, then link the updated discovery anchor.

package/skills/ultra-research/references/04-product-strategy.md

@@ -1,41 +0,0 @@
-# Product strategy
-
-Use for workflow step `04-product-strategy`.
-
-## Objective
-
-Turn accepted evidence into problem reality, falsifiable first-principle propositions,
-a product direction, target boundary, value proposition, and explicit tradeoffs.
-
-## Evidence and decisions
-
-- Derive constraints from prior research and current system behavior.
-- Ask the owner when a scope, customer, business, or risk decision is load-bearing.
-- Do not infer an MVP, reduced scope, release phase, or commercial posture.
-- Record exclusions only when the owner or an accepted constraint establishes them.
-- For each proposed `FP-*`, record evidence, causal consequence, and the falsifier or
-  revisit trigger. The ID becomes canonical only in an owner-accepted synthesis.
-
-## Record
-
-Update `discovery.md` with:
-
-- product direction and intended actors;
-- value delivered through observable behavior;
-- chosen tradeoffs and their rationale;
-- constraints, exclusions, and unresolved decisions;
-- the candidate `FP-* -> capability -> behavior -> outcome` causal chain;
-- any defensibility claim with its supporting evidence.
-
-Complete the step with decision and evidence references plus the updated output path.
-
-## Report trace
-
-In the area report, record `tradeoff` and `rationale`, then link the decision file or
-specification anchor to the problems, opportunities, or constraints that support it.
-
-## Adversarial challenge
-
-Before the owner checkpoint, challenge whether the proposed direction follows from the
-underlying problem and first principles, steel-man the best conflicting direction, and
-name evidence that would overturn the working North Star candidate.

package/skills/ultra-research/references/05-assumptions-validation.md

@@ -1,31 +0,0 @@
-# Assumptions and validation
-
-Use for workflow step `05-assumptions-validation`.
-
-## Objective
-
-Make load-bearing assumptions visible and define the smallest credible evidence needed
-to confirm or reject them.
-
-## Method
-
-- Extract assumptions from problem, opportunity, market, alternative, and strategy
-  claims.
-- Separate already verified facts from assumptions and owner decisions.
-- Prioritize by consequence and uncertainty only when prioritization affects the next
-  action; do not assign arbitrary scores.
-- Define a validation signal, evidence source, decision rule, owner, and recovery path.
-
-## Record
-
-Update `discovery.md` with the assumption ledger and validation state. Map unresolved
-load-bearing assumptions to blocking unknowns or gaps. Keep non-blocking future work
-out of the implementation task graph until the owner selects it.
-
-Link evidence and the updated specification anchor from the bounded area report written
-for this research run.
-
-## Report trace
-
-In the area report, record `category`, `consequence`, `validation_signal`,
-`success_rule`, `failure_rule`, and `ambiguous_rule`, then link the discovery anchor.

package/skills/ultra-research/references/10-user-personas.md

@@ -1,30 +0,0 @@
-# Actors and jobs
-
-Use for workflow step `10-user-personas`.
-
-## Objective
-
-Describe evidence-backed actors, their jobs, operating context, goals, constraints, and
-adoption barriers. A role or actor model is sufficient; do not invent demographic
-personas.
-
-## Evidence
-
-- Prefer observed workflows, access roles, support evidence, usage data, and owner
-  decisions.
-- Link each actor to a real entry point or intended behavior.
-- Mark unverified motivations and pain points as unknown.
-- In brownfield adoption, document the actors represented by current code and runtime,
-  even when product research is incomplete.
-
-## Record
-
-Update `product.md` with actor identity, job, context, current workflow, desired outcome,
-constraints, and evidence. Record priority only when it is an accepted decision.
-
-Complete the step with evidence references and the updated output path.
-
-## Report trace
-
-In the area report, record `job`, `current_workflow`, `goal`, and `constraint`, then
-link the actor heading in `product.md`.

package/skills/ultra-research/references/11-user-scenarios.md

@@ -1,28 +0,0 @@
-# User scenarios
-
-Use for workflow step `11-user-scenarios`.
-
-## Objective
-
-Trace the important current and intended journeys from trigger through outcome,
-including failure and recovery.
-
-## Method
-
-- Bind each scenario to an evidence-backed actor and entry point.
-- Describe the current path before proposing a changed path in brownfield adoption.
-- Include state changes, external systems, permissions, and observable outcomes.
-- Do not force a fixed scenario count or emotional narrative.
-
-## Record
-
-Update `product.md` with scenario id, actor, trigger, preconditions, current or intended
-flow, success outcome, failure outcome, recovery, and evidence. Mark gaps where runtime
-behavior and documentation disagree.
-
-Complete the step with evidence references and the updated output path.
-
-## Report trace
-
-In the area report, record `actor_id`, `trigger`, `preconditions`, `flow`, `success`,
-`failure`, and `recovery`, then link the scenario heading in `product.md`.

package/skills/ultra-research/references/20-user-stories.md

@@ -1,31 +0,0 @@
-# Behavioral requirements and acceptance
-
-Use for workflow step `20-user-stories`.
-
-## Objective
-
-Translate accepted scenarios into testable behavior without prematurely designing the
-implementation.
-
-## Method
-
-- Use stable requirement identifiers.
-- State preconditions, action, observable result, error behavior, and recovery where
-  relevant.
-- Trace every requirement to a scenario, constraint, or owner decision.
-- Preserve current delivered behavior separately from proposed behavior.
-- Do not use priority labels as a substitute for explicit scope decisions.
-
-## Record
-
-Update `product.md` with requirements and acceptance criteria that can map to an
-executable check or deliberate manual evidence. Record unknown behavior instead of
-writing vague acceptance.
-
-Complete the step with evidence references and the updated output path.
-
-## Report trace
-
-In the area report, record `preconditions`, `action`, `observable_result`,
-`error_recovery`, and `verification`. Link the requirement heading to its accepted
-scenario or decision.

package/skills/ultra-research/references/21-features-scope.md

@@ -1,38 +0,0 @@
-# Capability and scope boundary
-
-Use for workflow step `21-features-scope`.
-
-## Objective
-
-Group accepted behavior into coherent capabilities and record what is included,
-excluded, deferred, or unresolved.
-
-## Rules
-
-- Preserve the owner's stated product and release posture.
-- Never infer an MVP, reduced version, phase label, or omission from implementation
-  convenience.
-- Trace included capabilities to requirements and observable outcomes.
-- Trace each included capability to candidate `FP-*` and `NS-*` IDs, and name every
-  candidate `HC-*` it could breach, without copying North Star prose.
-- Record dependencies, migrations, compatibility, and operational obligations inside
-  the capability that owns them.
-- Keep speculative future ideas outside the active scope unless selected.
-
-## Record
-
-Update `product.md` with capability boundaries, included requirements, explicit
-exclusions and rationale, dependencies, and unresolved scope decisions.
-
-Complete the step with decision evidence and the updated output path.
-
-## Report trace
-
-In the area report, record `requirement_ids`, `scope_status`, and `rationale`, then link
-the capability heading in `product.md`.
-
-## Adversarial challenge
-
-Before the owner checkpoint, challenge whether every included capability causally serves
-the working North Star, whether an exclusion breaks that outcome or a hard constraint,
-and whether the proposed scope can optimize a proxy while missing delivered value.

package/skills/ultra-research/references/22-success-metrics.md

@@ -1,33 +0,0 @@
-# Outcomes and measurements
-
-Use for workflow step `22-success-metrics`.
-
-## Objective
-
-Define how the owner will know the accepted behavior and product outcome are working,
-including signals that would reveal harmful optimization.
-
-## Method
-
-- Derive measurements from accepted outcomes and available instrumentation.
-- State definition, source, observation window, owner, and decision use.
-- Separate current measurements, target decisions, and unavailable telemetry.
-- Propose one or more stable `NS-*` outcomes when justified by delivered value and a
-  credible observation contract. Each records observation method, baseline, target or
-  expected change, horizon, and anti-metric.
-- Do not force a single metric, or invent baselines and targets, when guardrails plus an
-  observable outcome represent the product more honestly.
-
-## Record
-
-Update `product.md` with supporting outcome measures, operational measures, guardrails,
-evidence availability, and unresolved instrumentation needs. Propose the canonical
-`NS-*` entries for `north-star.md`; they become authority only through accepted synthesis.
-A metric that cannot be observed is a gap or explicit future Change.
-
-Complete the step with evidence references and the updated output path.
-
-## Report trace
-
-In the area report, record `definition`, `source`, `window`, `owner`, and
-`decision_use`, then link the metric heading in `product.md`.

package/skills/ultra-research/references/30-architecture-context.md

@@ -1,30 +0,0 @@
-# Architecture context
-
-Use for workflow step `30-architecture-context`.
-
-## Objective
-
-Establish current system boundaries, quality goals, constraints, actors, external
-systems, and data flows.
-
-## Evidence
-
-- Inspect code entry points, configuration, schemas, deployment assets, tests, and
-  runtime evidence.
-- Separate observed architecture from intended architecture.
-- Record permissions, data sensitivity, compliance, and organizational constraints
-  when they affect the design.
-- Do not infer a greenfield architecture over an existing system.
-
-## Record
-
-Update `architecture.md` with system context, external dependencies, trust boundaries,
-data flows, quality goals, constraints, and evidence. Record documentation drift when
-the current checkout contradicts an existing diagram or claim.
-
-Complete the step with source or runtime evidence and the updated output path.
-
-## Report trace
-
-In the area report, record `boundary`, `inputs_outputs`, `trust_authority`, and
-`consumers`, then link the architecture heading.

package/skills/ultra-research/references/31-solution-strategy.md

@@ -1,28 +0,0 @@
-# Solution strategy
-
-Use for workflow step `31-solution-strategy`.
-
-## Objective
-
-Record architecture decisions that satisfy accepted behavior and constraints while
-preserving current repository patterns where they remain valid.
-
-## Method
-
-- Search for existing implementations and dependencies before proposing new ones.
-- Evaluate alternatives only when more than one credible choice remains and the choice
-  materially affects the contract.
-- Record decision drivers, chosen direction, consequences, compatibility, and recovery.
-- Do not force a new stack, fixed option count, scoring model, or arbitrary preference.
-
-## Record
-
-Update `architecture.md` with accepted strategy decisions and their evidence. Preserve
-unresolved decisions as blockers rather than selecting on the owner's behalf.
-
-Complete the step with decision evidence and the updated output path.
-
-## Report trace
-
-In the area report, record `drivers`, `direction`, `consequences`, `compatibility`, and
-`recovery`, then link the decision file or architecture heading.

package/skills/ultra-research/references/32-building-blocks.md

@@ -1,28 +0,0 @@
-# Building blocks and runtime paths
-
-Use for workflow step `32-building-blocks`.
-
-## Objective
-
-Map responsibilities, contracts, data ownership, consumers, and runtime behavior across
-the current or accepted architecture.
-
-## Method
-
-- Start from real modules and live entry points in brownfield adoption.
-- Define boundaries by responsibility and authority, not by an imposed layer diagram.
-- Trace key scenarios through validation, domain behavior, persistence, integrations,
-  observable output, failure, and recovery.
-- Identify unreachable scaffolding, duplicate authority, and undocumented coupling.
-
-## Record
-
-Update `architecture.md` with building blocks, public contracts, ownership, dependencies,
-runtime paths, error paths, and evidence. Link each proposed block to a consumer.
-
-Complete the step with source evidence and the updated output path.
-
-## Report trace
-
-In the area report, record `entry_point`, `state_side_effects`, `observable_result`,
-`failure_recovery`, and `consumers`, then link the architecture heading.

package/skills/ultra-research/references/40-deployment.md

@@ -1,29 +0,0 @@
-# Deployment and operations
-
-Use for workflow step `40-deployment`.
-
-## Objective
-
-Record how the system is built, configured, migrated, deployed, observed, recovered,
-and rolled back across its actual environments.
-
-## Evidence
-
-- Inspect repository-native build and deployment configuration, environment contracts,
-  migrations, health checks, and operational documentation.
-- Use current provider documentation only when repository evidence is insufficient.
-- Separate verified deployment behavior from intended delivery design.
-- Never record secrets or fabricate infrastructure that has not been selected.
-
-## Record
-
-Update `architecture.md` with environments, topology, CI/CD entry points, configuration,
-migrations, observability, rollback, recovery, cost constraints when relevant, and
-unknowns.
-
-Complete the step with file, runtime, or provider evidence and the updated output path.
-
-## Report trace
-
-In the area report, record `environment`, `entry_point`, `config_migration`,
-`observation`, and `rollback_recovery`, then link the architecture heading.