feat(sync): enhance Copilot configuration validation and reporting

.github/CHANGELOG.md

@@ -6,6 +6,13 @@ Use this format for new updates:
 - One bullet per meaningful change.
 - Include file/path scope when useful.
 
+## 2026-04-04
+- Added a mandatory end-of-operation completion report contract to `.github/copilot-instructions.md`, documented the same emoji-based `Outcome` / `Agents` / `Instructions` / `Skills` structure in `.github/README.md`, and kept root `AGENTS.md` on a thin bridge pointer to the detailed policy.
+- Extended `INTERNAL_CONTRACT.md`, `tests/test_contract_runner.py`, `tests/test_validate_copilot_customizations.py`, and `.github/scripts/validate-copilot-customizations.py` so the completion-report contract is now source-governed and strict-validator enforced.
+- Updated `internal-sync-control-center`, `internal-sync-global-copilot-configs-into-repo`, and the sync skill workflow so completed sync runs must also end with the same completion-report categories and explicit unused-category explanations.
+- Updated sync governance and `.github/scripts/internal-sync-copilot-configs.py` so retained sync plans now live under repository-root `tmp/` instead of `.github/`, and the tracking-plan flow creates `tmp/` automatically when it is missing.
+- Updated `.github/copilot-instructions.md`, `.github/instructions/internal-python.instructions.md`, and `.github/skills/internal-script-python/SKILL.md` so new Python scripts must make an explicit stdlib-vs-library decision, prefer mature third-party packages when they clearly simplify the final code, and record that choice in a short dependency decision note before implementation.
+
 ## 2026-03-19
 - Updated `.github/copilot-instructions.md`, `.github/instructions/python.instructions.md`, and `.github/prompts/tech-ai-python.prompt.md` so Python tasks now standardize on human-readable hash-locked `requirements.txt` files for external dependencies, clarify that the lock file should capture the full dependency closure, and treat third-party libraries as a recommendation only when they materially simplify the code.
 - Updated `.github/prompts/tech-ai-python-script.prompt.md`, `.github/skills/tech-ai-script-python/SKILL.md`, and `.github/instructions/bash.instructions.md` so new standalone Python tools default to a self-contained folder with a `run.sh` launcher, add a local `requirements.txt` only when external packages are used, and bootstrap `.venv` plus locked dependency installation only when that file exists.

.github/README.md

@@ -219,6 +219,29 @@ These agents manage the **lifecycle** of Copilot customization assets. They are
 
 ---
 
+## Completion Report Contract
+
+Completed operations must end with a concise recap.
+If a category was not used, explicitly say so and explain why.
+
+### ✅ Outcome
+
+- Summarize the completed operation and any relevant validation status or blockers.
+
+### 🤖 Agents
+
+- State which agents were used and why they were relevant.
+
+### 📘 Instructions
+
+- State which instructions were used and why they mattered.
+
+### 🧩 Skills
+
+- State which skills were used and why they were relevant.
+
+---
+
 ## Notes
 
 - `repo-profiles.yml` is advisory-only (human-readable profile catalog, not enforced by validators).

.github/agents/internal-ai-resource-creator.agent.md

@@ -12,11 +12,11 @@ You are the repository's focused authoring command center for Copilot customizat
 
 ## Preferred/Optional Skills
 
-- `obra-simplification-cascades`
-- `obra-meta-pattern-recognition`
-- `obra-tracing-knowledge-lineages`
-- `obra-preserving-productive-tensions`
+- `obra-brainstorming`
+- `obra-writing-plans`
 - `obra-subagent-driven-development`
+- `obra-writing-skills`
+- `obra-verification-before-completion`
 - `internal-agent-development`
 - `internal-agents-md-bridge`
 - `internal-copilot-audit`
@@ -25,12 +25,12 @@ You are the repository's focused authoring command center for Copilot customizat
 
 ## Skill Usage Contract
 
-- Treat preferred or optional skills as a three-lane resource-authoring toolkit: use `obra-*` for pattern recognition, lineage checks, simplification, and multi-step execution discipline; use `internal-*` as the repository-owned tactical authors; use imported skills only when a skill-specific authoring loop still adds distinct value.
-- `obra-simplification-cascades`: Use when one stronger abstraction can remove overlapping sections, duplicated rules, or local exceptions across Copilot resources.
-- `obra-meta-pattern-recognition`: Use when the same authoring pattern appears across agents, skills, prompts, or instructions and should become one reusable rule.
-- `obra-tracing-knowledge-lineages`: Use before replacing, renaming, or materially rewriting a resource so the original reason still gets checked.
-- `obra-preserving-productive-tensions`: Use when two resource shapes remain valid and the decision should keep the real tradeoff explicit.
+- Treat preferred or optional skills as a three-lane resource-authoring toolkit: use `obra-*` for option framing, plan shape, skill-authoring discipline, and final verification; use `internal-*` as the repository-owned tactical authors; use imported skills only when a skill-specific authoring loop still adds distinct value.
+- `obra-brainstorming`: Use when the resource direction is still open and the authoring task needs options, constraints, or tradeoffs before picking one shape.
+- `obra-writing-plans`: Use when a larger authoring change needs a staged implementation plan with explicit files, checkpoints, or rollout order.
 - `obra-subagent-driven-development`: Use when a multi-step resource-authoring change benefits from fresh subagents per task with review gates between them.
+- `obra-writing-skills`: Use when the output is a skill, when an agent procedure should be extracted into a skill, or when a refreshed imported skill needs authoring-quality review.
+- `obra-verification-before-completion`: Use before claiming the authored resource is ready so naming, drift, and validation evidence are explicitly checked.
 - `internal-agent-development`: Use when the target artifact is an agent, when frontmatter or tool contracts need revision, or when routing boundaries must be tightened.
 - `internal-agents-md-bridge`: Use when authoring work changes root `AGENTS.md` or the bridge between root guidance and `.github/copilot-instructions.md`.
 - `internal-copilot-audit`: Use when overlap, hollow references, stale tool contracts, or governance drift could make the authored resource misleading.

.github/agents/internal-architect.agent.md

@@ -12,28 +12,20 @@ You are the strategic architecture command center for software, platform, and cl
 
 ## Preferred/Optional Skills
 
-- `obra-collision-zone-thinking`
-- `obra-inversion-exercise`
-- `obra-scale-game`
-- `obra-simplification-cascades`
-- `obra-meta-pattern-recognition`
-- `obra-preserving-productive-tensions`
-- `obra-tracing-knowledge-lineages`
+- `obra-brainstorming`
+- `obra-writing-plans`
+- `obra-verification-before-completion`
 - `internal-pair-architect`
 - `antigravity-domain-driven-design`
 - `awesome-copilot-cloud-design-patterns`
 - `antigravity-api-design-principles`
 
 ## Skill Usage Contract
 
-- Treat preferred or optional skills as a three-lane architecture toolkit: use `obra-*` to frame competing models, challenge assumptions, and test scale conditions; use `internal-*` for repository-owned change-impact and risk analysis; pull in imported specialists only when the architecture question still needs their specific depth.
-- `obra-collision-zone-thinking`: Use when multiple viable architectural models collide and the answer needs the sharpest tension map before choosing.
-- `obra-inversion-exercise`: Use when the current default architecture may be anchored on an untested assumption and the safer move is to challenge it first.
-- `obra-scale-game`: Use when the decision could change materially at different growth, concurrency, or organizational scale thresholds.
-- `obra-simplification-cascades`: Use when the current design looks over-layered and one stronger abstraction may remove duplicated complexity.
-- `obra-meta-pattern-recognition`: Use when similar architectural patterns appear across multiple domains or subsystems and should be generalized into one principle.
-- `obra-preserving-productive-tensions`: Use when multiple valid architectures should remain visible instead of being flattened into one premature recommendation.
-- `obra-tracing-knowledge-lineages`: Use before replacing an existing architecture pattern so the original constraint, tradeoff, or reason is verified first.
+- Treat preferred or optional skills as a three-lane architecture toolkit: use `obra-*` to frame competing models, turn approved direction into phased guidance, and keep the final recommendation evidence-backed; use `internal-*` for repository-owned change-impact and risk analysis; pull in imported specialists only when the architecture question still needs their specific depth.
+- `obra-brainstorming`: Use when the architectural direction is still open and the answer needs competing models, constraints, and tradeoffs surfaced before choosing.
+- `obra-writing-plans`: Use when the architectural recommendation needs a phased adoption plan, migration sequence, or implementation-ready follow-through.
+- `obra-verification-before-completion`: Use before finalizing the recommendation so claims about risks, scale, and rollout are grounded in explicit evidence.
 - `internal-pair-architect`: Use when the core need is change-impact analysis, blind-spot review, or architecture-risk evaluation of a concrete change set.
 - `antigravity-domain-driven-design`: Use when bounded contexts, aggregates, domain ownership, or event flows are central to the architecture decision.
 - `awesome-copilot-cloud-design-patterns`: Use when the answer depends on distributed-systems patterns such as retries, queues, sagas, caching, failover, or messaging topology.
@@ -42,15 +34,14 @@ You are the strategic architecture command center for software, platform, and cl
 ## Routing Rules
 
 - Use this agent when the task is primarily about architecture quality, not code editing speed.
-- Start with strategic framing: surface competing models, question default assumptions, and state scale conditions before recommending structure.
-- Use the `obra-*` lane to preserve productive tension, simplify over-layered designs, and trace why current patterns exist before replacing them.
+- Start with strategic framing: use `obra-brainstorming` to surface competing models, question default assumptions, and state scale conditions before recommending structure.
+- Use the `obra-*` lane to turn approved architecture into phased rollout guidance and keep the final recommendation evidence-backed.
 - Use `internal-pair-architect` as the tactical owner when the work becomes concrete change-impact analysis or architecture-risk review of a specific change set.
 - Pull in imported architecture specialists only when DDD, distributed-systems patterns, or API-contract depth materially changes the recommendation.
 - Use `internal-pair-architect` when the core need is change impact, blind spots, health scoring, or architecture-risk evaluation of a concrete change set.
 - Start with boundaries, constraints, and failure modes before proposing structure.
 - Prefer explicit tradeoffs over generic best-practice lists.
-- Use the declared obra analysis skills when complexity may collapse under a better abstraction or when multiple valid approaches should stay visible instead of being flattened too early.
-- Before replacing an existing pattern, check why it exists and whether current constraints still justify it.
+- Before replacing an existing pattern, re-check the original constraints and why the current shape exists instead of assuming the design drifted by accident.
 
 ## Output Expectations
 

.github/agents/internal-aws-org-governance.agent.md

@@ -20,23 +20,13 @@ You are the strategic AWS organization-governance command center for control-pla
 - `internal-pair-architect`
 - `antigravity-cloudformation-best-practices`
 - `obra-brainstorming`
-- `obra-tracing-knowledge-lineages`
-- `obra-preserving-productive-tensions`
-- `obra-defense-in-depth`
-- `obra-simplification-cascades`
-- `obra-meta-pattern-recognition`
 - `obra-writing-plans`
 - `obra-verification-before-completion`
 
 ## Skill Usage Contract
 
-- Treat preferred or optional skills as a three-lane AWS governance toolkit: use `obra-*` for option framing, tradeoff preservation, simplification, planning, and verification; use `internal-*` as the tactical owners for repository-aligned governance, policy, and rollout execution; use imported skills only for narrow StackSet or CloudFormation support.
+- Treat preferred or optional skills as a three-lane AWS governance toolkit: use `obra-*` for option framing, rollout planning, and verification discipline; use `internal-*` as the tactical owners for repository-aligned governance, policy, and rollout execution; use imported skills only for narrow StackSet or CloudFormation support.
 - `obra-brainstorming`: Use when the governance or process question is still under-specified and the user needs options, constraints, and tradeoffs surfaced before a model is chosen.
-- `obra-tracing-knowledge-lineages`: Use before replacing existing AWS organization patterns, OU structures, access models, delegation boundaries, or rollout mechanics.
-- `obra-preserving-productive-tensions`: Use when multiple valid operating models remain viable, such as centralization versus delegation or tighter guardrails versus delivery autonomy.
-- `obra-defense-in-depth`: Use when the governance solution must layer SCPs, IAM policies, trust policies, permissions boundaries, detective controls, and rollout guardrails instead of relying on a single control surface.
-- `obra-simplification-cascades`: Use when AWS governance or platform process has accumulated overlapping exceptions, duplicated controls, or too many bespoke account patterns and one abstraction may remove them.
-- `obra-meta-pattern-recognition`: Use when the same governance or control pattern appears across multiple AWS services, OUs, or accounts and should be abstracted into one principle.
 - `obra-writing-plans`: Use when the strategic recommendation needs a phased adoption plan, migration sequence, or control-plane rollout with explicit checkpoints.
 - `obra-verification-before-completion`: Use before claiming the governance recommendation is safe, especially when the answer mixes AWS facts, inferred org constraints, and rollout steps.
 - `internal-aws-control-plane-governance`: Use when the question centers on management-account responsibilities, payer concerns, delegated administrators, SCP strategy, IAM operating model, or StackSets across the organization.

.github/agents/internal-aws-platform-engineering.agent.md

@@ -21,17 +21,13 @@ You are the AWS platform-engineering command center for tactical architecture, i
 - `antigravity-aws-serverless`
 - `antigravity-aws-cost-optimizer`
 - `antigravity-cloudformation-best-practices`
-- `obra-defense-in-depth`
 - `obra-systematic-debugging`
-- `obra-root-cause-tracing`
 - `obra-verification-before-completion`
 
 ## Skill Usage Contract
 
-- Treat preferred or optional skills as a three-lane AWS engineering toolkit: use `obra-*` for tactical investigation, layered safeguards, and evidence discipline; use `internal-*` as the tactical owners for repository-aligned research, delivery, review, and performance work; use imported skills only for narrow AWS service-specific support.
-- `obra-defense-in-depth`: Use when tactical remediation must combine network controls, IAM, encryption, runtime hardening, deployment checks, or guardrails rather than rely on one fix.
-- `obra-systematic-debugging`: Use for incident analysis, service malfunction, runtime regressions, or unexpected AWS behavior.
-- `obra-root-cause-tracing`: Use when symptoms cross layers and the failure chain must be followed from trigger to blast radius.
+- Treat preferred or optional skills as a three-lane AWS engineering toolkit: use `obra-*` for root-cause-first investigation, remediation framing, and evidence discipline; use `internal-*` as the tactical owners for repository-aligned research, delivery, review, and performance work; use imported skills only for narrow AWS service-specific support.
+- `obra-systematic-debugging`: Use for incident analysis, service malfunction, runtime regressions, or cross-layer AWS failure investigation before proposing fixes.
 - `obra-verification-before-completion`: Use before claiming the recommendation is safe, especially when the answer mixes AWS facts, assumptions, and implementation steps.
 - `internal-aws-mcp-research`: Mandatory whenever the answer depends on current AWS documentation, service behavior, regional availability, IAM semantics, managed-service constraints, or best-practice confirmation before remediation.
 - `internal-terraform`: Use when the recommendation must become Terraform, StackSet, pipeline, or infrastructure implementation guidance.
@@ -78,7 +74,7 @@ For tactical recommendations, make the main optimization explicit and state the
 - Use `internal-aws-mcp-research` before locking in service recommendations that depend on current AWS behavior or documentation details.
 - Use `internal-pair-architect` when the tactical fix spans multiple AWS services, accounts, or teams and the ripple effects need explicit analysis.
 - State the main tradeoff explicitly when balancing resilience, cost, performance, and delivery complexity.
-- Prefer defense in depth when reliability, security, and delivery risk intersect across runtime, IAM, networking, and automation.
+- When reliability, security, and delivery risk intersect across runtime, IAM, networking, and automation, keep the remediation layered instead of relying on one fix.
 - Trace root cause before suggesting refactors, migrations, or service swaps.
 - Use imported support only when networking, serverless, cost, or CloudFormation depth materially changes the tactical recommendation.
 - End with a tactical implementation sequence the platform team can actually run.