[SopalovicDjordje]

Component and requirement IDs

• Component: Authoring tool — laboratory drafts and templates (backend/Platform.Authoring), Team 11
• Requirements: AUT-01 (create and edit drafts), AUT-06 (templates for quick task creation)
• Author(s): SopalovicDjordje

Changes

• New module backend/Platform.Authoring (Domain / Application / Infrastructure) and test project backend/Platform.Authoring.Tests. Both are added to backend/SecurityLab.slnx, so the common CI job builds and tests them.
• AUT-01: LabContent (immutable, always valid), LabDraft (edit only in the Draft state, version number for concurrent edits), DraftService (create and edit use cases).
• AUT-06: immutable LabTemplate, three built-in templates (access control, log analysis, secure configuration), and copy-to-draft with a new ID and a recorded source template.
• Documentation: docs/components/AUT-authoring.md (architecture, DFD, security requirements, acceptance mapping), Team 11 row in docs/PROJECT_COMPONENTS.md, README updated with run/check instructions that use the solution file.
• No HTTP endpoints, database or audit events yet; they are listed as planned in the component document.
• Merge with main: the branch is based on the current main. .github/workflows/ci.yml is taken unchanged from main (the earlier separate authoring job was removed because the solution-wide CI job covers it).

Verification

• dotnet build backend/SecurityLab.slnx --configuration Release and dotnet test backend/SecurityLab.slnx --configuration Release --no-build (same as CI).
• Authoring tests: dotnet test backend/Platform.Authoring.Tests/Platform.Authoring.Tests.csproj --configuration Release — 55 NUnit test cases.
• Every path mentioned in the README exists in the repository.

Architecture and data flow

• Modular monolith module with three layers: Domain (rules, no dependencies), Application (use cases and ports), Infrastructure (read-only built-in templates).
• Flow: Teacher → API (planned) → DraftService → access decision (IAuthoringAccess) → domain rules → draft store (IDraftRepository) / template store (ITemplateRepository, read-only). The trust boundary is at the API; authorization runs on the server before any data is read or changed.
• Attempts never reference a draft; they are bound to an immutable published revision (REV-03), so editing a draft cannot affect them.
• Component and DFD diagrams: docs/components/AUT-authoring.md.

Security checks and negative tests

• Deny by default: an empty actor id is always denied; a student or non-author cannot create a draft, edit one, or copy a template, and nothing is stored.
• Another author cannot edit a draft. A missing draft and someone else's draft both return FORBIDDEN, so draft IDs cannot be probed.
• Stale edit (old version) returns CONFLICT and does not overwrite newer work.
• A draft that is In review cannot be edited (DRAFT_NOT_EDITABLE).
• Invalid input: empty, over-long or control-character titles, over-long goals, undefined lab types, empty IDs.
• Templates: the template ID cannot be reused as a draft ID; editing a copy leaves the template unchanged; two copies are independent.
• Drafts hold no secrets, and content setters are private so validation cannot be bypassed.

Dependencies

• No dependency on other teams' code. IAuthoringAccess is this module's own port; until the Identity/Access modules provide an adapter, tests use a fake.
• Planned integrations: Identity and access (IAccessDecision adapter), PostgreSQL repository and migration, HTTP endpoints once authentication exists, audit events (AUD-*), hand-off of draft content to REV-01/REV-02.
• Test packages: the same NUnit versions as backend/Platform.Tests.