This feature delivers section-level review controls for First Draft Generation so reviewers can approve content they want to keep, reject content that needs improvement, and trigger regeneration only for the rejected portions of a temporary draft. It solves the problem of all-or-nothing regeneration by preserving accepted sections, capturing reviewer guidance for rejected sections, and supporting a governed review flow where the draft remains read-only until it is either iteratively refined or promoted. It also reinforces the temporary-review model of first drafts by ensuring reviewers can make decisions per section without directly editing generated text, while retaining citations and reviewability. The technical work adds the API contract and service behavior needed to record section decisions and start selective regeneration runs. This includes a new SectionDecisionRequest DTO with optional regeneration instructions, approve and reject operations in FirstDraftService, and a TriggerSelectiveRegenerationAsync path that validates draft state, ETag concurrency, and regeneration eligibility before dispatching orchestration. The platform layers touched are the API endpoints for section approval, rejection, and regenerate actions; the application/service layer where decision state, locking, and regeneration scope are enforced; and the orchestration layer where SelectiveRegenerationOrchestrator regenerates only rejected sections while keeping approved content unchanged. Test coverage spans API, orchestration, and integration layers to verify status codes, locking behavior, citation refresh, and content-hash handling. Key constraints are that approval and rejection actions are only valid while the draft is AwaitingReview, If-Match is required to prevent stale updates, and regeneration must be blocked if another run is already in progress. Approved sections become locked and are excluded from regeneration scope; rejecting an already approved section is invalid; and regeneration without any rejected sections returns a validation error. Acceptance is signaled by approved section hashes remaining unchanged after regeneration, regenerated sections receiving new content hashes and citations, and failed orchestration restoring rejected sections when a hash consistency check detects an invalid outcome.
This feature delivers the update-draft path for First Draft Generation, allowing a user to generate a proposed revision of an existing platform object from Input Navigator selections and Work Package context, then review that draft against the prior object side by side. It solves the problem of understanding what changed in an AI-generated update before promotion by creating a temporary, reviewable draft with a pinned baseline version and a comparison view, while preserving the boundary that this feature does not gather context or allow direct editing in the draft UI. The implementation adds the comparison contract and update workflow across the API, orchestration, and test layers. A new DraftComparisonResponse DTO exposes artifact identity, prior object/version metadata, baseline capture timestamp, section-level diffs, and citations. FirstDraftService.TriggerGenerationAsync is extended for the update path to validate the requested target object, prevent conflicting active drafts for the same target, and create a baseline snapshot with the prior object version pinned at trigger time. The FirstDraftGenerationOrchestrator update branch schedules governance-skill processing after section generation to compute SectionDiffs, stores them in the draft comparison snapshot, and updates the artifact. FirstDraftService.GetComparisonAsync reads the stored comparison data and maps it to the API response, while a new GET /workspaces/{workspaceId}/workpackages/{workPackageId}/first-drafts/{draftId}/comparison endpoint returns the comparison for update drafts under Work Package read authorization. Acceptance is signaled by service and integration coverage for the key constraints and edge cases: triggering an update without UpdateTargetObjectId fails with 422, attempting a second active update draft for the same target fails with 409, a valid update trigger returns 202 and captures the baseline priorObjectVersionId, and comparison retrieval returns 404 for scratch drafts but returns populated SectionDiffs for update drafts.
Foundation tasks, project setup, shared infrastructure, and cross-cutting concerns not tied to a specific user story.
This feature delivers the first end-to-end draft generation flow for a Work Package when no prior platform object exists. It solves the gap between curated source material in Input Navigator and a reviewable output by allowing a user to trigger an automated first draft from inherited Work Package context plus a selected output template, then review the temporary result before any promotion to a real object. The feature also establishes the lifecycle controls around that temporary artifact so teams can retrieve it, list it, promote it when approved, or reject it when it should be discarded, while preserving citations back to the originating input sources. The implementation adds the API contract, service logic, orchestration, and HTTP surface needed to create and manage first drafts. On the API layer, a FirstDraftResponse DTO is introduced and new endpoints are registered under the work package route for trigger, list, get, promote, and reject operations with capability checks and expected HTTP semantics. In the application and orchestration layers, FirstDraftService validates prerequisites, blocks duplicate active drafts, creates the draft artifact in InProgress, starts the generation workflow for the scratch path, delegates retrieval to the repository, and enforces lifecycle transitions for promotion and rejection. The solution also touches persistence and storage integration by mapping repository results into response models, updating Work Package run summaries, deleting staged content blobs on rejection, scheduling cleanup on promotion, and emitting audit events for terminal actions. The feature is intentionally constrained to the from-scratch journey in this increment and does not gather or edit context in the first-draft UI; it only consumes Input Navigator and Work Package outputs. Acceptance signals include correct error handling for missing prerequisites as 422 with named fields, 409 when an active draft already exists or a draft is not in AwaitingReview, and 412 when If-Match validation detects a stale ETag on promote or reject. Test coverage confirms that generated drafts can be triggered and retrieved, that all sections and citations are mapped correctly, and that promotion and rejection produce the expected state changes, cleanup behavior, and audit records.