| name | feasibility-study |
| description | Route feasibility-study using exact migration registry [{"unit":"feasibility-study/default","routing":{"positive_triggers":["Assess whether the proposed cache can be delivered within the stated technical and resource constraints.","Compare credible implementation approaches with evidence, uncertainty, effort bands, and risk.","Evaluate repository feasibility before committing to a technical design."],"negative_boundaries":["Decide whether the proposed feature is necessary for users or the business.","Document the final component architecture and integration ownership.","Write the implementation-ready technical specification and work breakdown."]}}]. |
Feasibility Study
Evaluate whether and how a stated outcome can be delivered under verified technical, compatibility, resource, and operational constraints. Compare credible approaches, expose uncertainty, and recommend the next validation or design step.
Stay within feasibility. Do not decide whether the feature is necessary, invent product requirements, finalize component architecture, write an implementation-ready technical specification, modify production code, create execution tickets, or mutate external systems.
1. Frame the decision
Restate the requested outcome, observable success signals, known constraints, and the decision the study must support. Separate user statements, repository observations, current external facts, and inferences. Record assumptions that could reverse the conclusion.
If the question is actually whether the outcome is worth pursuing, hand it to necessity analysis. If requirements are materially ambiguous, stop at explicit questions. If a technical design is already selected and only its details remain, continue in technical specification or deep design analysis.
2. Collect bounded evidence
Inspect relevant modules, tests, interfaces, configuration, dependency boundaries, similar implementations, failure paths, and operational constraints. Keep version-control inspection read-only. Cite repository-relative file locations for consequential claims.
When collaboration is available, assign at most one read-only repository investigator to trace reusable patterns, blockers, and validation seams while the main analysis builds the constraint register. A second independent challenger is warranted only after a recommendation exists and material uncertainty remains. When collaboration is unavailable, disclose that limitation and complete both checks locally.
