[ADR-161] Working PR for Layout customization backend service

.claude/commands/add-to-spec.md

@@ -0,0 +1,126 @@
+---
+description: Add a new requirement or task to an existing _spec_*.md file, iterating with the user until the content is ready
+argument-hint: <Jira issue key or brief description of the new requirement>
+---
+
+## Requirement to add
+
+Jira Task $ARGUMENTS
+
+## Available spec files
+
+!`find . -name "_spec_*.md" -not -path "./.git/*" | sort`
+
+## Available architecture docs
+
+!`find . -name "_doc_*.md" -not -path "./.git/*" | sort`
+
+## Workflow
+
+This is an iterative process. Follow the phases below. Never skip ahead —
+always wait for user input at each pause point before continuing.
+
+---
+
+### Phase 1 — Orient and gather context
+
+1. Identify the target spec file. If ARGUMENTS contains a Jira key, fetch the issue.
+   The target spec should be determined by the Jira work item's parent.
+   If the target spec is not obvious, ask the user which spec to add to.
+2. Read the spec file in full. Note: existing tasks, task numbering, insertion point,
+   and patterns (checklist format, Gherkin scenarios, exit criteria structure).
+3. Read any `_doc_*.md` files relevant to the area the new requirement touches.
+
+Then ask the user a focused set of questions to fill gaps the Jira description and spec
+don't answer. Good questions cover:
+
+- Scope boundaries (what this task owns vs. defers)
+- Integration points with existing tasks or services
+- Key design choices where multiple reasonable approaches exist
+- Whether new patterns established here must be retrofitted to earlier tasks
+
+Ask all your questions at once. Skip anything you can already answer.
+
+**PAUSE — wait for the user's answers before continuing.**
+
+If answers raise new ambiguities that materially affect the content, ask one more targeted
+follow-up round. Otherwise proceed to Phase 2.
+
+---
+
+### Phase 2 — Draft the new content
+
+1. Draft any new spec sections and update existing sections to reflect new decisions.
+2. Draft the new task section using the existing spec's task format:
+   - `### Task N — <title> ([ADR-XXX](<url>))`
+   - One-paragraph description
+   - Checklist items (`- [ ] ...`)
+   - Gherkin-style acceptance scenarios for any items that describe observable behavior
+3. Identify any exit criteria that should be added to other tasks:
+   - Patterns this task establishes that all future tasks must follow
+   - Stubs or placeholders in earlier tasks that this task replaces
+4. Determine the new task number and which existing tasks (if any) need renumbering.
+
+Write the draft to the spec file:
+- Insert the new task at the correct position
+- Update any other tasks with new exit criteria
+- Renumber task headings if needed (ADR links and checklist content are never changed
+  by renumbering — only the `### Task N —` prefix)
+
+After writing, tell the user:
+
+> Draft written to `<path>`. Please review it — edit any section directly and add
+> `> **Review:** your comment or question` anywhere you want a change made. Tell me
+> when you're ready for the next pass.
+
+**PAUSE — wait for the user to review and signal readiness.**
+
+---
+
+### Phase 3 — Iterative refinement
+
+When the user signals they're ready:
+
+1. Re-read the spec file.
+2. Collect all `> **Review:** ...` markers and any direct edits.
+3. Address review comments **one at a time** in document order:
+   a. Present your analysis — trade-offs and recommendation.
+   b. **PAUSE — wait for the user's decision before editing.**
+   c. Update the spec; remove the review marker.
+   d. State what changed; move to the next comment.
+4. After all comments are resolved, invite another review pass.
+
+Repeat Phase 3 until the user says the content is ready.
+
+---
+
+### Phase 4 — Implementation readiness review
+
+Read the requirements from the perspective of a code agent assigned to implement them with
+no additional context. Ask:
+
+- Can you implement every checklist item without guessing?
+- Can you write unit tests and Gherkin scenarios without guessing at expected behavior?
+- Are there missing error cases, unspecified interfaces, or ambiguous behavior?
+- Does new content interact with existing tasks in ways that need to be reflected there
+  (e.g., a new pattern that earlier tasks must also adopt, or a stub that a later task
+  will replace)?
+
+If you find gaps, list them all and ask clarifying questions (all at once).
+
+**PAUSE if you asked questions — wait for answers before continuing.**
+
+Otherwise proceed to Phase 5.
+
+---
+
+### Phase 5 — Jira update
+
+Update the Jira task's description: replace initial design notes with a concise summary of
+the finalized spec content. Include:
+- A one-paragraph overview of what this task implements
+- A bulleted list of key decisions and their outcomes
+- A reference to the spec file: `See spec: <relative path>`
+
+The original Jira description may contain early "initial thoughts" that are now superseded;
+replace it entirely rather than appending.

.claude/commands/team-task.md

@@ -114,7 +114,7 @@ Researcher instructions:
 
 ### Phase 2 — Developer, first pass (Sonnet)
 
-Spawn a Developer agent with `model: sonnet`. Pass it:
+Spawn a Developer agent with `model: claude-sonnet-4-6`. Pass it:
 
 - The task brief (full text from Researcher)
 - Task key, base branch
@@ -311,7 +311,7 @@ git rev-parse HEAD
 
 Store this as `REVIEWER_BASELINE`.
 
-Spawn a Reviewer agent with `model: sonnet`. Pass it the PR URL, branch, and base branch.
+Spawn a Reviewer agent with `model: claude-sonnet-4-6`. Pass it the PR URL, branch, and base branch.
 
 Reviewer instructions:
 
@@ -364,7 +364,7 @@ Reviewer instructions:
 
 ### Phase 6 — Developer, review pass (Sonnet)
 
-Spawn a Developer agent with `model: sonnet`. Pass it the PR URL, branch, and task brief.
+Spawn a Developer agent with `model: claude-sonnet-4-6`. Pass it the PR URL, branch, and task brief.
 
 Developer instructions:
 

.claude/settings.local.json

@@ -7,7 +7,12 @@
       "Bash(xargs:*)",
       "mcp__jira__createJiraIssue",
       "mcp__jira__editJiraIssue",
-      "mcp__jira__getJiraProjectIssueTypesMetadata"
+      "mcp__jira__getJiraProjectIssueTypesMetadata",
+      "Bash(dotnet build *)",
+      "Bash(dotnet test *)",
+      "Bash(curl -s http://localhost:4566/_localstack/health)",
+      "Bash(git add *)",
+      "Bash(gh pr *)"
     ]
   }
 }

.github/workflows/build-and-test.yml

@@ -32,18 +32,19 @@ jobs:
       run: dotnet restore
 
     - name: Build
+      id: build
       run: dotnet build --no-restore /warnaserror
 
     - name: Install Chromium browser for Playwright headless tests
       shell: pwsh
       run: pwsh ./src/AdaptiveRemote.Headless/bin/Debug/net10.0/playwright.ps1 install chromium
 
     - name: Unit Tests 
-      run: dotnet test --no-build --verbosity normal --logger trx --results-directory "TestResults" ./scripts/validate-unit-tests.proj
+      run: dotnet test --no-build --verbosity normal --logger trx --results-directory "TestResults" ./scripts/validate-unit-tests.proj --filter "TestCategory!=ApiIntegrationTest"
 
     - name: E2E Tests
       run: dotnet test --no-build --verbosity normal --logger trx --results-directory "TestResults" ./scripts/validate-e2e-tests.proj -m:1
-      if: always()
+      if: always() && steps.build.outcome == 'success'
 
     - name: Upload E2E Test Logs
       uses: actions/upload-artifact@v6
@@ -60,3 +61,40 @@ jobs:
       with:
         files: |
           TestResults/**/*.trx
+
+  backend-api-tests:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      checks: write
+      pull-requests: write
+
+    steps:
+    - name: Checkout code
+      uses: actions/checkout@v6
+      with:
+        fetch-depth: 0
+
+    - name: Setup .NET
+      uses: actions/setup-dotnet@v5
+      with:
+        dotnet-version: '10.0.x'
+
+    - name: Restore dependencies
+      run: dotnet restore backend.slnf
+
+    - name: Build
+      run: dotnet build backend.slnf --no-restore /warnaserror
+
+    - name: Pull LocalStack image
+      run: docker pull localstack/localstack:3.0
+
+    - name: API Integration Tests
+      run: dotnet test --no-build --verbosity normal --logger trx --results-directory "TestResults" ./test/AdaptiveRemote.Backend.ApiTests/AdaptiveRemote.Backend.ApiTests.csproj -m:1
+
+    - name: Publish Test Results
+      uses: EnricoMi/publish-unit-test-result-action@v2
+      if: always()
+      with:
+        files: |
+          TestResults/**/*.trx