dotnet-task-context-investigator

name	dotnet-task-context-investigator
description	Investigate all direct and indirect .NET repository context for a documented BA task, including related entities, permissions, workflows, tests, and persistence. Use after task analysis and before requirement-gap resolution.

.NET Task Context Investigator

Purpose

Return to the repository with task terminology and establish what existing code, data relationships, workflows, and reusable components directly affect the requested behavior.

When to use

Use after dotnet-task-analyzer. Re-run when clarification changes a task rule or reveals a new related domain concept.

Assumptions

• The task requirements are structured and retained verbatim.
• The initial repository map is available but cannot substitute for detailed task-specific investigation.
• A relationship may be indirect, for example through users, roles, assignments, files, statuses, or a shared service.

Required inputs

• Task Requirement Report.
• Project Documentation Report and Project Understanding Report.
• Team Coding Pattern Report.
• Repository root and workspace protection boundaries.
• Task dossier state and evidence registry when resuming.
• Cached project index when resuming.

Workflow

1. Build search terms from requirement IDs, domain names, endpoint names, entity names, related entities, permissions, roles, statuses, business terminology, and database terminology in the task.
2. When a dossier exists, reuse only current architecture and pattern claims from .otto/project-index.md or the latest project reports. Start from the task's dependency graph and expand one relationship at a time when evidence requires it; do not reopen unrelated modules merely because they share technical layers.
3. Search definitions and references. Inspect directly related documentation, entities, mappings/configurations, DTOs, endpoints, handlers or services, authorization, validations, tests, migrations, workflows, relationships, and analogous behavior.
4. Follow indirect relationships. For example, a task that prevents deletion for assigned records requires inspection of the assignment owner, relationship mapping, queries, and assignment creation paths—not merely the record's delete endpoint.
5. Identify existing reusable components and candidate references. Search for existing services, repositories, handlers, validators, utility methods, storage implementations, extension methods, shared error/response builders, and business logic before proposing a new implementation. Document what is structurally reusable, why it satisfies the requirement, and what differs in business meaning.
6. For every new or changed API, inspect the local controller or endpoint documentation style, request/response examples, validation descriptions, error response conventions, and any existing API documentation tests. Record whether documentation can be improved locally without changing global Swagger, Scalar, or OpenAPI configuration.
7. For every field that may require a table column or persisted attribute, trace its purpose, business meaning, type, nullability, constraints, relationships, default, update behavior, and business rules through task, documentation, entities, mappings, migrations, and usage. Mark any missing item as unknown; do not approve a schema change from analogy.
8. Compare observed behavior with task wording. Record task/code conflicts, missing codebase support, unsupported dependencies, missing database relationships, documentation gaps, and scope boundaries without resolving business ambiguity. Keep investigation read-only and do not plan or implement changes.

Evidence priority

Use this order for any interpretation: 1) resolved task requirements, 2) original task requirements, 3) repository instructions and documentation, 4) approved merge requests, 5) resolved review comments, 6) recent merged code, 7) repeated current project patterns, 8) similar implementations, 9) generic .NET practices. Generic practices never override explicit task or project rules.

Safety rules

• Do not modify code, migrations, configuration, data, or Git state.
• Do not infer a business rule just because a similar module has one.
• Do not treat a candidate reference as proof that its business semantics apply.
• Observe workspace protection boundaries and redact secrets in evidence.

Stop conditions

Stop when the repository is unreadable, a required related component is unavailable, or investigation exposes a missing task decision that must be classified by the next skill. Do not proceed to planning.

Required output

Produce a Task Context Report, using ../../templates/task-context-report.md. Include relevant files, related modules and relationships, reusable components, current behavior, candidate references, API documentation conventions and gaps, database-field findings, conflicts, missing support, search terms, and direct evidence. Map findings to requirement IDs and evidence-registry IDs; record the explored dependency boundary and any uninspected but unrelated areas.

Handoff to the next skill

Pass the Task Context Report and all prior reports to dotnet-requirement-gap-analyzer.