feat: bootstrap first mcp server baseline

.claude/settings.json

@@ -0,0 +1 @@
+{}

.devcontainer/README.md

@@ -0,0 +1,25 @@
+# Devcontainer
+
+This repository supports development in the Eclipse S-CORE devcontainer image.
+
+## What happens automatically
+
+When the container is created, VS Code runs the post-create command from [devcontainer.json](devcontainer.json):
+
+1. Install project dependencies with `uv sync --all-groups`.
+2. Install git hooks with `uv run pre-commit install --install-hooks`.
+
+When the container starts, VS Code runs the post-start command to refresh the local SSH known-host entry used by the workspace tooling.
+
+## Daily workflow
+
+1. Reopen the repository in container.
+2. Run tests: `uv run pytest -xvs`.
+3. Run checks: `uv run ruff check src/ tests/` and `uv run basedpyright src/`.
+4. Run hooks manually if needed: `uv run pre-commit run --all-files`.
+
+## Troubleshooting
+
+- If tools are missing, run `uv sync --all-groups` manually.
+- If hooks are missing, run `uv run pre-commit install --install-hooks` manually.
+- To verify runtime availability from MCP, call the `server_health` tool.

.devcontainer/devcontainer.json

@@ -0,0 +1,6 @@
+{
+    "name": "eclipse-s-core",
+    "image": "ghcr.io/eclipse-score/devcontainer:v1.5.0",
+    "postCreateCommand": "uv sync --all-groups && uv run pre-commit install --install-hooks",
+    "postStartCommand": "ssh-keygen -f '/home/vscode/.ssh/known_hosts' -R '[localhost]:2222' || true"
+}

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,33 @@
+## Description
+
+<!-- What does this PR do? Reference the issue. -->
+
+Fixes #
+
+## Changes
+
+<!-- Brief list of changes -->
+
+-
+
+## Testing
+
+<!-- How was this tested? -->
+
+- [ ] Unit tests added/updated
+- [ ] Integration tests added/updated (if tool calls external programs)
+- [ ] All tests pass: uv run pytest
+- [ ] Lint passes: uv run ruff check src/ tests/
+- [ ] Type check passes: uv run basedpyright src/
+
+## AI Disclosure
+
+- [ ] This PR contains AI-assisted code or documentation
+
+<!-- If checked: -->
+**Tool(s) used:**
+<!-- e.g., GitHub Copilot, Claude Code, Devin, Cursor -->
+
+**Verification:**
+- [ ] I have reviewed and understand all AI-generated code
+- [ ] All AI-assisted commits include an Assisted-by: trailer

.github/copilot-instructions.md

@@ -0,0 +1,46 @@
+You are operating inside the SCORE governance overlay.
+
+This file is runtime-specific glue.
+The canonical, runtime-neutral policy lives in AGENTS.md at repository root.
+
+Keep this file aligned with AGENTS.md and use it only for assistant-runtime specifics.
+Update distributed policy files by running `copier update` from the repository root.
+
+## Responsibilities
+
+1. Preserve issue-first traceability — all work artifacts reference a GitHub issue number.
+2. Honour SCORE contracts:
+   - `.github/references/repo-manifest.schema.json`
+   - `.github/references/agent-card.schema.json`
+   - `.github/score/repo-manifest.json`
+3. Apply coding standards from `.github/instructions/`.
+
+Terminology note: `.github/references/agent-card.schema.json` defines a SCORE work/handoff artifact, not an A2A service-discovery AgentCard.
+
+## Artifact Naming
+
+Use issue-scoped stage folders for all work artifacts:
+
+```
+.stage/ISSUE-<number>/
+  plan.md
+  work-card.json
+```
+
+## SDLC Progress Block
+
+Paste this into every response when tracking work:
+
+### SDLC Progress -- <ISSUE-ID>
+- [ ] PLAN -- Not Started
+- [ ] CODE -- Not Started
+- [ ] BUILD -- Not Started
+- [ ] TEST -- Not Started
+- [ ] RELEASE -- Not Started
+
+## Governance Rules
+
+- Do not embed large agent/prompt catalogs here.
+- Use an upstream SDD framework (Spec Kit, OpenSpec, BMAD) for workflow orchestration.
+- Keep this file and `.github/instructions/` as the only SCORE-specific overlay.
+- If AGENTS.md and this file conflict, treat AGENTS.md as the canonical project policy and reconcile the files.

.github/copilot/settings.json

@@ -0,0 +1 @@
+{}

.github/instructions/clean-code.instructions.md

@@ -0,0 +1,93 @@
+---
+applyTo: '**'
+---
+
+# Clean Code Guidelines (All Languages)
+
+## Goal
+Code is *extremely readable*, composed of *very small and focused* methods/functions, and avoids all code smells.
+
+## General Principles
+- Code is for **humans first**, computers second
+- Express intent clearly -- self-explanatory names for variables, methods, classes
+- Prefer self-documenting code; comments as last resort
+- **Small is beautiful** -- small, focused methods and classes
+- Duplication is a bad sign -- extract and reuse
+- KISS -- reduce complexity as much as possible
+- YAGNI -- avoid over-engineering
+- Boy Scout Rule -- leave the codebase cleaner than you found it
+- Tell, Don't Ask -- promote loose coupling
+- Be Consistent -- follow existing conventions
+- Encapsulate boundary conditions in one place
+- Avoid negative conditionals
+- Use dependency injection
+
+## SOLID Principles
+- **SRP**: Each method/class does one thing only
+- **OCP**: Open for extension, closed for modification
+- **LSP**: Subtypes substitutable for base types
+- **ISP**: Small, focused interfaces
+- **DIP**: Depend on abstractions, not concretions
+
+## Code Smells to Remove
+Long Method, Large Class, Primitive Obsession, Long Parameter List (max 3), Data Clumps, Switch Statements, Temporary Field, Divergent Change, Shotgun Surgery, Duplicated Code, Dead Code, Feature Envy, Middle Man, Magic Numbers (replace with named constants).
+
+## Class Design
+- Small: max ~7 fields, ~3-5 public methods
+- Single clear purpose aligned with domain
+- Domain-focused naming (e.g. `PolicyRenewalService`, not `HelperUtil`)
+- Encapsulation -- hide internal structure
+- Prefer immutability, composition over inheritance
+- Follow Law of Demeter
+- Prefer value objects over primitives
+- Avoid God objects and util classes
+
+## Method Design
+- Ideal length: ~3 lines, rarely more than 5
+- Single atomic step of logic
+- Names describe *what* not *how*
+- No side effects
+- Use guard clauses / early returns
+- Avoid nested ifs/loops
+- No flag arguments -- split into separate methods
+- Extract complex predicates into named boolean methods
+
+## Test Design
+- Small, specific, isolated, fast, independent, repeatable
+- Arrange-Act-Assert format
+- Max 3 assertions per test
+- Always test new public behavior
+- At least one negative test per API
+- Avoid duplicated test data -- extract to class level
+
+## Naming
+- Descriptive and unambiguous
+- Methods: verbs. Classes: nouns. Variables: clear names
+- Pronounceable, searchable, no encodings
+
+## Comments
+- Explain *why*, not *what*
+- Document assumptions, invariants, edge cases
+- Never comment out code -- just remove it
+
+## Error Handling
+- Use domain-specific custom exceptions
+- Handle exceptions gracefully; never swallow them
+- Externalize user-facing messages
+- Maintain ErrorCode mapping
+
+## Security
+- No hardcoded secrets, URLs, or sensitive info
+- All sensitive config resolved via environment or config server
+- PII protection: data masking, tokenization
+
+## Performance
+- Avoid premature micro-optimizations unless profiled
+- Batch operations in single transactions
+- Refactor nested loops into indexed maps (O(n+m))
+
+## API Design
+- RESTful conventions with domain-driven design
+- Plural noun resources: `/v1/templates`
+- Accept filtering & expansion parameters
+- Consistent resource naming

.github/instructions/coding-style.instructions.md

@@ -0,0 +1,65 @@
+---
+applyTo: '**'
+---
+
+# Coding Style
+
+## Immutability (CRITICAL)
+
+ALWAYS create new objects, NEVER mutate existing ones:
+- Return new instances rather than modifying in place
+- Use spread operators, `List.copyOf()`, `Map.copyOf()`, or equivalent
+- Mark fields `final` / `readonly` / `const` by default
+
+Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
+
+## File Organization
+
+MANY SMALL FILES > FEW LARGE FILES:
+- High cohesion, low coupling
+- 200-400 lines typical, 800 max
+- Extract utilities from large modules
+- Organize by feature/domain, not by type
+
+## Function Size
+
+- Ideal: 3-10 lines, rarely more than 20
+- Max: 50 lines — split if exceeded
+- Single atomic step of logic per function
+- No flag arguments — split into separate functions
+
+## Nesting
+
+- Max 4 levels of nesting
+- Use guard clauses and early returns to flatten
+- Extract complex predicates into named boolean methods
+- Extract inner loops into helper functions
+
+## Error Handling
+
+ALWAYS handle errors comprehensively:
+- Handle errors explicitly at every level
+- Provide user-friendly error messages in UI-facing code
+- Log detailed error context on the server side
+- Never silently swallow errors
+
+## Input Validation
+
+ALWAYS validate at system boundaries:
+- Validate all user input before processing
+- Use schema-based validation where available
+- Fail fast with clear error messages
+- Never trust external data (API responses, user input, file content)
+
+## Code Quality Checklist
+
+Before marking work complete:
+- [ ] Code is readable and well-named
+- [ ] Functions are small (<50 lines)
+- [ ] Files are focused (<800 lines)
+- [ ] No deep nesting (>4 levels)
+- [ ] Proper error handling at every level
+- [ ] No hardcoded values (use constants or config)
+- [ ] No mutation (immutable patterns used)
+- [ ] No `console.log` / `System.out.println` in production code
+- [ ] No TODO/FIXME without a linked issue

.github/instructions/git-workflow.instructions.md

@@ -0,0 +1,51 @@
+---
+applyTo: '**'
+---
+
+# Git Workflow
+
+## Commit Message Format
+```
+<prefix>: <summary>
+
+<optional body>
+
+<optional footer: Also-by: Name <email>>
+```
+
+### Types
+`feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`, `style`
+
+### Rules
+- Use imperative mood: "add feature" not "added feature"
+- Keep subject line under 72 characters
+- One logical change per commit
+- Run `gitlint` locally before pushing
+
+## Branch Naming
+Format: `<type>/<short-description>`
+
+Examples:
+- `feature/add-login`
+- `bugfix/fix-null-pointer`
+- `hotfix/auth-patch`
+
+## Pull Request Workflow
+1. Analyze full commit history: `git diff <base-branch>...HEAD`
+2. Draft comprehensive PR summary covering what changed and why
+3. Include a test plan with verification steps
+4. Push with `-u` flag if new branch
+5. Request review from at least one peer
+
+## Pre-Commit Checklist
+- [ ] All tests pass locally
+- [ ] No lint errors or warnings
+- [ ] No `console.log` / `System.out.println` left in production code
+- [ ] No TODO/FIXME without a linked issue
+- [ ] Commit message follows format above
+- [ ] Branch is rebased on latest base branch
+
+## Merge Strategy
+- Use squash merge when all commits are from the same author and represent one topic
+- Use rebase/merge commit when commits represent distinct topics or multiple authors
+- Preserve clear history and avoid merge commits from `main` into feature branches