This feature delivers the user-facing exploration surface for staged inputs after processing, including rendered HTML inspection, structure browsing, natural-language search, and saved selections of document parts for downstream operations. It solves the need to make staged plain-text inputs explorable and selectively reusable without promoting them into governed content prematurely. The implementation extends the InputNavigator service with HTML rendering and structure extraction driven by staged file content plus indexed chunk metadata, including short-lived memory caching keyed by input updates. It also adds a dedicated search service scoped strictly by workspace and Work Package, returning chunk-level evidence rather than fabricated answers, and a selection service that persists named sets of section-level references for later use. Corresponding API endpoints are added for HTML, structure, search, and CRUD operations over selections, and the workflow completion path is integrated so reprocessing an input marks dependent selections stale. Important constraints here come directly from the spec: only processed and eligible text inputs can be rendered or selected, search must always be filtered to the active Work Package, binary or excluded inputs must not be treated as analyzable text, and selection updates must honor ETag concurrency. Acceptance is demonstrated by unit and integration tests showing HTML and structure generation, scoped semantic search behavior, stale selection marking on reprocessing, and correct rejection of binary parts.
This feature delivers natural-language search over staged Input Navigator content within the active Work Package, so users can find relevant uploaded material and inspect evidence before that material becomes completed governed content. It solves the problem of users needing a reliable way to query staged inputs without crossing work package boundaries, while also making search behavior honest and traceable by returning only indexed matches, never fabricated answers, and clearly signaling when a hit comes from content that was not eligible for plain-text analysis. The implementation adds an Input Navigator search service and API surface in the platform API layer. IInputSearchService and InputSearchService are built to call the Azure AI Search abstraction with mandatory workspaceId and workPackageId scoping, apply the workPackageId eq '{workPackageId}' filter on every request, forward the user query verbatim, and map search hits into InputSearchResult records containing input object identity, staged file identity, file metadata, paragraph and section references, snippet text, relevance score, and an isTextAnalyzed flag derived from eligibility metadata. A new POST /search endpoint is added under the Input Navigator endpoints to validate the request body, reject empty queries with 422, and return a consistent { query, totalHits, results } payload. The feature is constrained to staged input that has already passed through the existing Stage → Process → Index pipeline, and its retrieval scope is always limited to the current workspace and work package. Acceptance is demonstrated through unit tests that verify mandatory work package filtering, correct binary-hit flagging, verbatim query forwarding, and empty-array behavior for no matches, plus an integration journey proving that known staged content is discoverable in the target work package, content from a different work package is not returned, and no-match queries produce totalHits: 0 with results: [].
This feature enables Input Navigator users to create a Work Package together with a fully defined scoping template in a single governed action, so staged input can be tied immediately to the retrieval and insight-generation structure that will be used later. It solves the gap between uploading and exploring input and formally configuring how that input should be analyzed, by ensuring the Work Package is created as an Input Navigator work package and that any supplied scoping template is complete, valid, and attached from the start. It also prevents partially configured work from entering the system, which is especially important because template sections, search questions, sample answers, and agent model selection directly drive downstream insight behavior. The implementation extends the API request contract for work package creation to accept an optional scoping template payload with sections and agent configuration, and adds strict validation rules that return a 422 with the scoping-template-incomplete error when required fields are missing. On the service layer, a new IScopingTemplateService and ScopingTemplateService are introduced to validate and persist scoping templates as Cosmos documents, while WorkPackageService.CreateAsync() is updated to create the Work Package, create the template, patch the foreign key back onto the Work Package, and roll back the Work Package if template creation fails. The feature also adds an Input Navigator-specific read endpoint to retrieve the full scoping template by workspace and work package, touching the API models, endpoint layer, domain/service orchestration, persistence/repository integration, and automated test coverage across unit and integration levels. Key constraints are atomicity and completeness: if any section lacks SearchQuestions or SampleAnswers, or if AgentConfiguration.ModelId is empty, no Work Package may remain created. Acceptance is signaled by successful creation returning a Work Package with WorkPackageTypeId set to input-navigator and a linked scopingTemplateId, by retrieval of the stored template including all sections and agent configuration, and by failure cases proving that incomplete template submissions return 422 and leave no partial Work Package or template artifacts behind.
This feature ensures that insights generated from staged Input Navigator content are preserved when an Input Navigator work package is completed, so the work package record retains a durable summary of the analysis that informed the work. It solves the gap where staged insight artifacts are useful during processing but could otherwise remain only temporary, making it harder to audit what was generated, which fulfillment outputs were involved, and what evidence belonged to the completed work package history. By retaining those insights and embedding a compact retention summary into the completed work package, the platform keeps Input Navigator output traceable without changing the temporary, work-in-progress behavior of staging. The implementation adds a retention operation to the Input Navigator service layer that enumerates all TemporaryInsightObject records for a given work package, marks each as retained, and returns a NavigatorRetentionSummary containing the relevant input object identifiers, fulfillment report identifiers, and aggregate counts. The work package completion path in the API service layer is extended to invoke this retention step during completion and persist the returned summary onto the work package record. The work touches the Input Navigator domain/service logic, temporary insight repository access, and the Work Package completion flow, with test coverage added at both unit and integration levels to verify retention state changes, summary content, and completed work package persistence. A key constraint is that insight retention is best effort: failure to retain insights must not prevent work package completion. Acceptance is signaled when completing a work package after fulfillment results in the work package GET response containing a NavigatorRetentionSummary with the expected FulfillmentReportId values, while the related TemporaryInsightObject records are marked with isRetained = true; if retention fails, the work package must still complete successfully without propagating that failure as a completion blocker.
This feature delivers context-governed insight generation for Input Navigator inputs by allowing a staged input object to explicitly trigger the processing pipeline that prepares it for retrieval and analysis within its Work Package scope. It solves the gap between file upload and usable workpackage evidence by ensuring only eligible inputs enter processing, preventing duplicate concurrent runs, selecting the correct plain-text or document-conversion path, and moving the input through clear processing states until insights are available or failed. The result is a governed, traceable way to turn uploaded source material into searchable, workpackage-bound analysis inputs that support template-driven retrieval and interactive Q&A with citations. The technical work adds a pipeline trigger operation to the Input Navigator service layer, exposes it through a new API endpoint, and wires the feature into the platform workflow/orchestration layer by creating workflow runs against the Input Navigator pipeline definition. It updates input-object persistence with the current pipeline run identifier and processing state, adds a workflow completion handler that listens for run completion and progress events, and uses the realtime notification layer to publish progress and completion updates back to clients. The implementation touches API endpoints, application services, repositories, workflow integration, event subscription/callback handling, realtime notifications, and the indexing path that ultimately produces AI Search chunks filtered by workPackageId. The feature is constrained by the Input Navigator staging model and its plain-text analysis boundary: plain-text sources go through the direct parser path, while non-plain-text formats must first be converted before only plain-text output is indexed. Acceptance is signaled by a 202 response with a workflow run ID when triggering succeeds, correct 422 and 409 protections for ineligible or already-processing inputs, observable state transitions from Eligible to Processing to InsightsAvailable or ProcessingFailed, realtime progress/completion notifications, and integration evidence that indexed chunks are written with the correct Work Package association.
This feature delivers the final lifecycle step where temporary insight artifacts are retained with the completed Work Package record, and it closes the implementation with endpoint manifests, validation scripts, and full regression coverage. It solves the specification requirement that insights remain workpackage-specific during processing but become part of completed Work Package history without blocking completion if retention encounters issues. The implementation adds retention behavior to the InputNavigator service, updates the Work Package completion path to invoke it in a best-effort manner, and verifies that retained insight summaries are embedded back into the Work Package record. Around that, it updates endpoint snapshots and architecture manifests, expands the journey tests into a continuous end-to-end scenario, runs repository and agent-surface validations, enforces context-budget limits on new files, and finishes with full build and test execution. The critical constraint is resilience: insight retention failure must not prevent Work Package completion, but successful cases must leave both retained temporary insight objects and a summary trace on the completed Work Package. Acceptance for this feature is therefore both functional and operational, combining retention-specific tests with guardrail, manifest, and solution-wide validation signals that indicate the entire Input Navigator slice is production-ready.
This feature enables users to inspect staged Input Navigator content as a readable explorer view by turning processed uploaded files into rendered HTML and navigable document structure within the scope of a Work Package. It solves the problem of having parsed, indexed input that is technically available but not easily explorable by users who need to review source material, confirm what was processed, and trace plain-text evidence before downstream governed work proceeds. The capability is explicitly limited to eligible plain-text analysis, so users get a consistent inspection experience for supported inputs while ineligible binary content is clearly rejected instead of being rendered ambiguously. The technical work adds rendering and structure retrieval to the Input Navigator service and exposes both through API endpoints. IInputNavigatorService and InputNavigatorService are extended with GetRenderedHtmlAsync(workspaceId, workPackageId, inputObjectId) and GetStructureAsync(workspaceId, workPackageId, inputObjectId). The implementation reads staged file content from blob storage through IStagingFileService, queries AI Search chunk metadata filtered by stagedFileId, reconstructs heading and paragraph hierarchy from chunk metadata, and produces structured HTML plus a section tree response. The API layer is updated with GET /input-objects/{inputObjectId}/html returning text/html and GET /input-objects/{inputObjectId}/structure returning structured JSON, while in-memory caching with a five-minute TTL keyed by inputObjectId + updatedAt reduces repeated blob reads and render cost. The feature must honor processing and eligibility boundaries defined by the staging pipeline. Rendered HTML is only available after processing completes, returning 404 for inputs not yet processed and 422 for inputs marked ineligible such as excluded binary files. Acceptance is demonstrated through unit coverage for heading extraction, state and eligibility failures, and cache-hit behavior, plus end-to-end journey tests proving that a completed pipeline yields explorable HTML and section structure for supported inputs and rejects binary input with the expected 422 response.
This feature delivers the core staging flow that turns uploaded files into governed input objects tied to a Work Package, including automatic default Work Package creation when needed. It solves the primary problem in the specification: uploaded source material must enter a workpackage-bound staging area with explicit eligibility, traceability, and a processing lifecycle before any insights or downstream use can occur. The implementation spans foundational backend architecture first, then the ingestion and pipeline flow. It introduces the Input Navigator model set for input objects and realtime events, extends Work Package and Azure options, creates repository interfaces and Cosmos implementations, wires dependency registration, and adds the seeded two-path workflow definition for plain-text versus non-plain-text processing. On top of that, it adds the InputNavigator service and API endpoints for creating, listing, fetching, and triggering processing of input objects, plus workflow completion handling and realtime notifications so pipeline progress and completion are reflected back into InputObject state and pushed to workspace listeners. Key constraints are central to acceptance here: eligibility must be determined from content type, duplicate staged-file plus Work Package creation must behave idempotently with 409 handling, non-eligible inputs cannot be processed, and processing concurrency must be rejected. Completion is signaled by end-to-end tests proving upload-to-input-object creation, pipeline triggering, state transitions to InsightsAvailable or ProcessingFailed, workspace-scoped indexing metadata, and repository and notification behavior all working together.
This feature delivers the ability for users to save named selections of document parts within the Input Navigator so those curated sections can be reused as explicit context for downstream work. It solves the problem of treating an entire staged document as the only usable unit of context by letting users preserve just the relevant sections from workpackage-bound input objects, while also protecting correctness when referenced content is reprocessed or when unsupported binary-derived parts are supplied. The result is a governed, reusable selection artifact tied to a Work Package, with clear validation, traceability, and stale-state signaling when the underlying input changes. The technical work adds an InputSelection domain flow in the API service and endpoint layers, backed by repository persistence and audit emission. A new IInputSelectionService and InputSelectionService handle create, read, list, update, and delete operations, validate that selected parts belong to input objects in the current Work Package, reject excluded binary parts with a 422 binary-part-rejected response, enforce ETag concurrency on updates, and mark selections stale when a referenced input object is reset for reprocessing. The API surface is extended with /selections endpoints for CRUD operations, and the existing Input Navigator workflow completion handling is updated so pipeline re-triggering calls the staleness logic before processing state transitions, touching the orchestration integration point as well as the Input Navigator application layer and test suite. Acceptance is signaled by service and journey coverage that proves section-level selections can be created and later supplied to downstream operations as only the chosen section identifiers, that re-triggering processing on a referenced input object flips isStale to true, that binary-backed parts are rejected with the expected 422 behavior, and that update requests honor If-Match semantics with 412 on ETag mismatch. The feature remains constrained to workpackage-scoped Input Navigator content and plain-text-eligible document parts, preserving the platform rule that unsupported or excluded input should not become valid analytical selection context.
This feature delivers the context-governed analysis layer for the Input Navigator by attaching scoping templates to Work Packages and running fulfillment analysis against indexed staged inputs. It solves the problem of turning staged source material into workpackage-specific insight records that reflect template coverage, evidence citations, and hosted-agent analysis under Work Package Context. The implementation adds the remaining domain models for scoping templates, fulfillment reports, temporary insight objects, and selection artifacts, then extends Work Package creation so an Input Navigator flow can create a Work Package with an atomic scoping template payload. It adds a scoping template service and retrieval endpoint, validation rules that reject incomplete templates without partial Work Package creation, a fulfillment analysis service and endpoints, and a seeded hosted-agent workflow that executes template search questions against AI Search filtered by Work Package. Workflow completion handling updates report status, creates temporary insight objects, and pushes realtime progress and completion events. Acceptance depends on preserving workpackage scoping and evidence discipline throughout the flow: fulfillment cannot run without a template or at least one indexed input, sections must return explicit coverage states and citations, and template validation must reject missing search questions, sample answers, or model configuration atomically. The tests in this feature prove Work Package creation with template linkage, workflow-driven fulfillment completion, citation-rich reports, and correct 422 behavior for missing prerequisites.
This feature delivers the first usable Input Navigator flow for staging workpackage input from uploaded files. It solves the gap between raw staged uploads and governed workpackage analysis by turning a staged file into a traceable Input Object that is bound to a Work Package, or to a default Work Package when none is supplied. The result is a consistent, workpackage-scoped record of what was uploaded, whether it is eligible for plain-text processing, and how it should participate in later parsing, indexing, and insight generation, while preventing duplicate creation for the same staged file and work package. The implementation adds a dedicated IInputNavigatorService and InputNavigatorService in the API service layer, plus new Input Navigator endpoint mappings under /api/workspaces/{workspaceId}/input-navigator/work-packages/{workPackageId}/input-objects. The service looks up staged files through the staging layer, determines eligibility from content type, creates a default Work Package through the Work Package service when needed, updates staged-file workpackage references, persists the new InputObject through the repository layer, emits an audit event, and leaves the object in NotProcessed state while pipeline triggering is prepared for later phases. The API surface supports create, list, and get operations, and the endpoint group is wired into the platform-wide endpoint registration so the feature is exposed as part of the main application API. The scope is intentionally constrained to plain-text oriented analysis readiness, with images marked ExcludedBinary and other unsupported formats marked ExcludedUnsupported rather than entering the text-processing path. Acceptance is signaled by unit coverage for eligibility, default Work Package creation, duplicate detection, missing staged-file handling, and audit emission, plus integration coverage proving the end-to-end journey from staged upload to 201 Created, correct linkage fields, NotProcessed state, automatic default Work Package behavior, exclusion handling, and 409 idempotency on duplicate submission.
This feature adds fulfillment analysis to the Input Navigator so users can see how well staged, work package–scoped inputs satisfy the active scoping template before downstream work proceeds. It solves the current gap between simply indexing uploaded plain-text inputs and understanding whether those inputs actually cover the template’s required sections and search questions. Users can trigger an analysis for a work package, receive a queued report, track progress, and review a completed fulfillment report that shows section-by-section coverage states such as Covered, Partial, or Missing, backed by citations into the staged source material. It also enforces the governance model by refusing analysis when no scoping template exists or when the work package has no eligible inputs with insights available. The implementation introduces a dedicated fulfillment analysis service in the API layer, new Input Navigator endpoints to trigger and retrieve reports, and a completion handler that reacts to hosted workflow execution results. A seeded hosted-agent workflow is added in the Azure platform layer to iterate the scoping template sections, execute each section’s search questions against AI Search filtered by workPackageId, evaluate coverage using ranked results and calibration inputs, and emit citation data for each result. The feature touches the API services and endpoint surface, workflow/orchestration integration through IWorkflowService, repository persistence for FulfillmentReport and TemporaryInsightObject documents, AI Search retrieval, hosted agent execution activities, and realtime notification delivery for progress and completion. Acceptance is signaled by a 202 response with a reportId when analysis is successfully queued, 200 responses for listing and retrieving work package reports, and 422 errors with stable codes when prerequisites are missing, specifically no-scoping-template and no-indexed-inputs. On successful workflow completion, the report must transition from Queued to Completed, every returned section must have a coverage status, covered sections must include at least one citation with a non-empty paragraphId and snippet, a TemporaryInsightObject must be created, and realtime progress and completion notifications must be emitted; failures must instead mark the report as Failed.
No description available
No description available
No description available
No description available
No description available
No description available
No description available
No description available