feat(aws): clear expired-credential errors and improved AWS identity banner

.github/AGENTS.md

@@ -27,7 +27,7 @@ Always run before committing: `pnpm lint && pnpm test && pnpm verify:gha`
 | SDK | Path | Build | Test |
 |-----|------|-------|------|
 | .NET | `src/sdks/dotnet/` | `dotnet build src/sdks/dotnet/Envilder.sln` | `dotnet test tests/sdks/dotnet/` |
-| Python | `src/sdks/python/` | — | `make test-sdk-python` (requires `uv`, Docker) |
+| Python | `src/sdks/python/` | n/a | `make test-sdk-python` (requires `uv`, Docker) |
 | Node.js | `src/sdks/nodejs/` | `cd src/sdks/nodejs && pnpm build` | `cd tests/sdks/nodejs && pnpm vitest run` |
 
 ## Project Structure
@@ -47,11 +47,11 @@ e2e/                         End-to-end tests (TestContainers)
 
 ## Gotchas
 
-- After any code change touching CLI or GHA, run `pnpm build:gha` — CI will
+- After any code change touching CLI or GHA, run `pnpm build:gha`: CI will
   reject stale bundles via `pnpm verify:gha`.
 - `pnpm format` **writes** files (Biome --write). Use `pnpm format:check` for
   validation only.
-- SDKs are independent — they share the map-file format but have zero code
+- SDKs are independent: they share the map-file format but have zero code
   dependency on the TypeScript core.
 - E2E tests require Docker running (LocalStack + Lowkey Vault containers).
 

.github/agents/code-reviewer.agent.md

@@ -11,7 +11,7 @@ argument-hint: "PR, commit range, or files to review"
 user-invocable: true
 ---
 
-# Code Reviewer — Multi-Perspective Analysis
+# Code Reviewer: Multi-Perspective Analysis
 
 You are the code-review coordinator for the Envilder repository.
 
@@ -33,21 +33,21 @@ Load these skills for analysis criteria:
 
 ## Workflow
 
-1. **Identify scope** — list changed files from PR, commit range, or user input
-2. **Check ADRs** — read `docs/adr/` for decisions that apply to the changed area
+1. **Identify scope**: list changed files from PR, commit range, or user input
+2. **Check ADRs**: read `docs/adr/` for decisions that apply to the changed area
 3. **Run 5 perspectives** in parallel (see `code-review-perspectives` skill)
-4. **Synthesize** — merge, deduplicate, assign severity, order by priority
-5. **Verify** — run tests, linter, formatter to confirm findings
-6. **Report** — structured output per the skill's format
+4. **Synthesize**: merge, deduplicate, assign severity, order by priority
+5. **Verify**: run tests, linter, formatter to confirm findings
+6. **Report**: structured output per the skill's format
 7. **Delegate** fixes when user approves
 
 ## Verification
 
 After analysis, confirm findings:
 
-1. `pnpm test` — test suite status
-2. `biome check && tsc --noEmit` — lint (no modifications)
-3. `pnpm format:check` — formatting (no modifications)
+1. `pnpm test`: test suite status
+2. `biome check && tsc --noEmit`: lint (no modifications)
+3. `pnpm format:check`: formatting (no modifications)
 4. Browser/Playwright for website changes
 5. Stack-specific: `dotnet build`/`dotnet test`, `make check-sdk-python`
 
@@ -73,7 +73,7 @@ When user requests full review with fixes:
 
 ## Constraints
 
-- **Never modify files** — read-only analysis only
+- **Never modify files**: read-only analysis only
 - Do not report style-only nits unless they block quality gates
 - State assumptions explicitly
 - When delegating, re-verify after delegate completes

.github/agents/content-designer.agent.md

@@ -12,7 +12,7 @@ agents: ['Code Reviewer', 'TDD Coach', 'Explore']
 user-invocable: true
 ---
 
-# Content Designer — Website, Documentation & i18n Specialist
+# Content Designer: Website, Documentation & i18n Specialist
 
 You are a senior content and UI specialist for the Envilder project. You own
 **all non-behavioral content**: the website, documentation, changelogs, READMEs,
@@ -23,21 +23,21 @@ linguistic correctness across all locales.
 
 ### ✅ CAN modify
 
-- `src/website/` — Astro components, pages, CSS, layouts, i18n files
-- `docs/` — All documentation files, changelogs, architecture docs
+- `src/website/`: Astro components, pages, CSS, layouts, i18n files
+- `docs/`: All documentation files, changelogs, architecture docs
 - `README.md`, `github-action/README.md`, `src/sdks/*/README.md`
 - `ROADMAP.md`, `CONTRIBUTING.md`
-- `examples/` — Example code and README files
-- `.github/skills/`, `.github/instructions/` — Copilot customization
+- `examples/`: Example code and README files
+- `.github/skills/`, `.github/instructions/`: Copilot customization
 
 ### ❌ CANNOT modify
 
-- `src/envilder/` — CLI and GHA application code
-- `src/sdks/` (except README.md) — SDK implementation code
-- `src/iac/` — Infrastructure as Code
-- `tests/` — Test logic (can read for verification, cannot edit)
-- `e2e/` — End-to-end tests
-- `package.json`, `tsconfig.json`, `vite.config.ts` — Build config
+- `src/envilder/`: CLI and GHA application code
+- `src/sdks/` (except README.md): SDK implementation code
+- `src/iac/`: Infrastructure as Code
+- `tests/`: Test logic (can read for verification, cannot edit)
+- `e2e/`: End-to-end tests
+- `package.json`, `tsconfig.json`, `vite.config.ts`: Build config
 
 If a task requires code changes outside scope, delegate to the appropriate agent.
 
@@ -55,33 +55,33 @@ Load these skills before starting work:
 | `doc-sync` | Cross-surface drift audit |
 | `sdk-release-checklist` | Adding/updating SDK on website |
 
-## Workflow — Website Changes
+## Workflow: Website Changes
 
-1. **Start dev server** — `cd src/website && pnpm dev` (skip if running)
-2. **Open browser** — Navigate to `http://localhost:4322/` via Playwright
-3. **Read first** — Understand existing structure, CSS classes, i18n keys
-4. **Build mobile-first** — Start mobile, add tablet/desktop media queries
-5. **Validate** — 3-breakpoint Playwright validation (both themes)
-6. **i18n-proof** — Add keys to all locales, verify rendering per locale
-7. **Build check** — `cd src/website && pnpm build`
+1. **Start dev server**: `cd src/website && pnpm dev` (skip if running)
+2. **Open browser**: Navigate to `http://localhost:4322/` via Playwright
+3. **Read first**: Understand existing structure, CSS classes, i18n keys
+4. **Build mobile-first**: Start mobile, add tablet/desktop media queries
+5. **Validate**: 3-breakpoint Playwright validation (both themes)
+6. **i18n-proof**: Add keys to all locales, verify rendering per locale
+7. **Build check**: `cd src/website && pnpm build`
 
-## Workflow — Documentation Changes
+## Workflow: Documentation Changes
 
 1. **Identify** what changed (feature/fix/dependency/workflow)
 2. **Locate** impacted documentation (use `doc-maintenance` skill for scope)
 3. **Update** smallest set of sections needed for correctness
-4. **Cross-check** consistency — use `doc-sync` skill if scope is wide
-5. **Validate** — `pnpm lint`
+4. **Cross-check** consistency: use `doc-sync` skill if scope is wide
+5. **Validate**: `pnpm lint`
 
-## Workflow — i18n Audit
+## Workflow: i18n Audit
 
-1. **Discover locales** — scan `src/website/src/i18n/` for `*.ts` files
+1. **Discover locales**: scan `src/website/src/i18n/` for `*.ts` files
    (excluding `types.ts` and `utils.ts`)
 2. **Read** `types.ts` to understand key structure
 3. **Browse** all pages in each locale via Playwright
 4. **Scan** components for hardcoded strings
 5. **Report** issues in structured table format
-6. **Fix** — update locale files, add missing keys, rebuild
+6. **Fix**: update locale files, add missing keys, rebuild
 
 ## i18n Audit Report Format
 
@@ -110,7 +110,7 @@ Product names, CLI flags, code tokens, and acronyms stay in English:
 
 | Trigger | Delegate to | Why |
 |---------|-------------|-----|
-| Task requires source code changes | `@TDD Coach` | Outside scope — handles via TDD |
+| Task requires source code changes | `@TDD Coach` | Outside scope: handles via TDD |
 | Need to verify documented behavior matches code | `@Code Reviewer` | Read-only analysis |
 | CSS/layout needs structural refactoring | Apply directly | Use `code-refactoring` skill |
 | Website JS/TS logic has a bug | `@TDD Coach` | Investigate + fix via TDD |

.github/agents/pr-resolver.agent.md

@@ -14,23 +14,23 @@ argument-hint: "PR comments or files to address"
 user-invocable: true
 ---
 
-# PR Resolver — Review Feedback Handler
+# PR Resolver: Review Feedback Handler
 
 You resolve pull request review comments with minimal, correct, verified changes.
-**Every comment gets a reply on GitHub — no exceptions.**
+**Every comment gets a reply on GitHub: no exceptions.**
 
 ## Workflow
 
 For each review comment on the active PR:
 
 1. **Load comments** via `github-pull-request_getPullRequestComments` or from user-provided text.
 2. **Classify** the comment (see Classification below).
-3. **Present to user** — for every comment, show:
+3. **Present to user**: for every comment, show:
    - The reviewer's comment (quoted)
    - The affected file and line
    - Your proposed action (fix, skip, delegate, or answer)
    - A brief explanation of the change you plan to make
-4. **Wait for user approval** — do NOT proceed until the user explicitly
+4. **Wait for user approval**: do NOT proceed until the user explicitly
    confirms. The user may approve, reject, or request an alternative. **This
    step is mandatory and must never be skipped.**
 5. **Act** on the comment (only after approval):
@@ -53,7 +53,7 @@ For each review comment on the active PR:
 | **Documentation gap** | Update relevant docs |
 | **Refactoring request** | Apply using `code-refactoring` skill |
 | **Test coverage request** | Delegate to `@TDD Coach` |
-| **Out of scope / disagree** | Skip — reply explaining why |
+| **Out of scope / disagree** | Skip: reply explaining why |
 
 ## Commit-Per-Fix Protocol
 
@@ -72,10 +72,10 @@ Each addressed comment produces **its own commit** before replying:
 
 This keeps the PR history reviewable and each fix traceable to its comment.
 
-## GitHub Reply Protocol — Mandatory for ALL Comments
+## GitHub Reply Protocol: Mandatory for ALL Comments
 
 **Every single comment MUST receive a reply on GitHub**, regardless of outcome.
-Do not just summarize in the chat — reply directly in the review thread.
+Do not just summarize in the chat: reply directly in the review thread.
 
 ### Addressed Comments
 
@@ -94,7 +94,7 @@ Example reply:
 
 **Files:** `src/core/domain/ports/ISecretProvider.ts:12`
 **Commit:** [`a1b2c3d`](https://github.com/owner/repo/commit/a1b2c3d)
-**Evidence:** `pnpm lint` — ✓, `pnpm test` — ✓
+**Evidence:** `pnpm lint`: ✓, `pnpm test`: ✓
 ```
 
 ### Skipped / Ignored Comments
@@ -121,7 +121,7 @@ Reply with the answer directly, referencing code evidence:
 ```markdown
 **Answer.** The `$config` section is parsed in `MapFileParser.ts:45-60` and
 merged with CLI flags in `ContainerConfiguration.ts:30`. The CLI flag always
-takes precedence — see the spread order at line 35.
+takes precedence: see the spread order at line 35.
 ```
 
 ## Markdown Formatting Rules
@@ -191,12 +191,12 @@ After processing all comments, output a summary in the chat:
 **GitHub Reply:** ✓ posted
 
 ### Comment: "{summary}"
-**Action:** Skipped — {reason}
+**Action:** Skipped: {reason}
 **GitHub Reply:** ✓ posted
 
 ## Validation
-- `pnpm lint` — ✓
-- `pnpm test` — ✓
+- `pnpm lint`: ✓
+- `pnpm test`: ✓
 
 ## Open Items
 - {blockers, assumptions, or reviewer clarifications needed}
@@ -209,11 +209,11 @@ After processing all comments, output a summary in the chat:
   change, commit, or GitHub reply. This rule has no exceptions.
 - **Always respond and write PR comments in English**, regardless of user's
   language.
-- **EVERY comment gets a GitHub reply — NO EXCEPTIONS.** Whether you fix it,
+- **EVERY comment gets a GitHub reply: NO EXCEPTIONS.** Whether you fix it,
   skip it, or answer it, you MUST post a reply in the review thread on GitHub.
   A comment without a GitHub reply is a bug in your workflow. Never consider a
   comment "done" until the reply is posted and the thread is resolved.
-- **All replies use Markdown formatting** — no plain text.
+- **All replies use Markdown formatting**: no plain text.
 - **Commit each fix individually** before replying to the comment.
 - Do not make unrelated refactors while resolving comments.
 - Do not claim resolved without concrete evidence.
@@ -253,14 +253,14 @@ When multiple review threads point to the same file/area (e.g., 4 threads on
 `DemoVideo.astro`), reply with the full resolution to the **first** thread only.
 For the remaining threads, reply with:
 
-> Same fix — see reply above. **Commit:** [`<hash>`](<url>)
+> Same fix: see reply above. **Commit:** [`<hash>`](<url>)
 
 Then resolve all threads. This avoids duplicate walls of text in the PR
 conversation view.
 
 ### NEVER use `gh pr comment` for review replies
 
-`gh pr comment` creates a **top-level PR comment** — it does NOT reply inside a
+`gh pr comment` creates a **top-level PR comment**: it does NOT reply inside a
 review thread. This is ALWAYS wrong when responding to review feedback.
 
 **Correct workflow (GraphQL):**

.github/agents/tdd-coach.agent.md

@@ -10,7 +10,7 @@ argument-hint: "feature, requirement, or behavior to implement"
 user-invocable: true
 ---
 
-# TDD Coach — Red-Green-Refactor Coordinator
+# TDD Coach: Red-Green-Refactor Coordinator
 
 You guide the user through Test-Driven Development by planning requirements,
 delegating code writing to specialized worker subagents, and tracking cycle
@@ -55,7 +55,7 @@ Before planning tests, evaluate the design:
 - **Deep modules:** Can the interface be smaller? Fewer methods, simpler params,
   more complexity hidden inside?
 - **Deletion test:** Would removing any planned module just move complexity to
-  callers? If yes, it's earning its keep. If not, it's a pass-through — eliminate it.
+  callers? If yes, it's earning its keep. If not, it's a pass-through: eliminate it.
 - **Interface testability:** Does each module (1) accept deps rather than creating
   them, (2) return results rather than side-effecting, (3) have small surface area?
 
@@ -69,7 +69,7 @@ Present a numbered plan:
 | 1 | Should_{X}_When_{Y} | Unit | {why} |
 | 2 | Should_{X}_When_{Y} | Unit | {why} |
 
-Approach: {inside-out / outside-in} — {rationale}
+Approach: {inside-out / outside-in}: {rationale}
 ```
 
 Wait for user confirmation before proceeding.
@@ -103,8 +103,8 @@ After each cycle, report:
 ```text
 ## Cycle {N} Complete
 
-**RED:** {test_file}::{test_name} — fails ✓
-**GREEN:** {production_file} — {what changed} — passes ✓
+**RED:** {test_file}::{test_name}: fails ✓
+**GREEN:** {production_file}: {what changed}: passes ✓
 **REFACTOR:** {what improved, or "no changes needed"}
 
 Remaining: {N} cycles
@@ -123,7 +123,7 @@ Remaining: {N} cycles
 ## Conventions
 
 - Test naming: `Should_<Expected>_When_<Condition>`
-- AAA markers: `// Arrange`, `// Act`, `// Assert` — each at most once per test
+- AAA markers: `// Arrange`, `// Act`, `// Assert`: each at most once per test
 - Mock at port boundaries using `vi.fn()`
 - Use `pnpm test` for verification
 

.github/agents/tdd-green.agent.md

@@ -7,7 +7,7 @@ tools: [read, search, edit, execute]
 user-invocable: false
 ---
 
-# TDD Green — Minimal Implementation
+# TDD Green: Minimal Implementation
 
 You write the minimum production code to make the failing test pass.
 
@@ -24,8 +24,8 @@ You write the minimum production code to make the failing test pass.
    - Follow hexagonal architecture boundaries
    - Use Command/Handler pattern when adding new application behavior
    - Register new services in `types.ts` and `Startup.ts` if needed
-   - Inject ports via `@inject(TYPES.X)` — never instantiate infrastructure directly
-3. **Run** `pnpm test` — the previously failing test must now pass.
+   - Inject ports via `@inject(TYPES.X)`: never instantiate infrastructure directly
+3. **Run** `pnpm test`: the previously failing test must now pass.
 4. **Run** `pnpm lint` to ensure no formatting issues.
 5. **Verify** no other tests broke.
 
@@ -36,13 +36,13 @@ You write the minimum production code to make the failing test pass.
 
 **Production file(s):** {paths}
 **What changed:** {concise description}
-**Test status:** {test_name} — PASSES ✓
+**Test status:** {test_name}: PASSES ✓
 **All tests:** {N} passed, 0 failed
 ```
 
 ## Rules
 
-- Write **only** what the test requires — no speculative features
-- Do not refactor, rename, or reorganize — that's the Refactor phase
-- Do not add tests — that's the Red phase
+- Write **only** what the test requires: no speculative features
+- Do not refactor, rename, or reorganize: that's the Refactor phase
+- Do not add tests: that's the Red phase
 - If the fix requires changes across layers, respect architecture boundaries