Move planned work from docs to prioritized GitHub issues

CONTRIBUTING.md

@@ -24,6 +24,13 @@ instructions when prompted.
 3. Update documentation when behavior, setup, deployment, or public APIs change.
 4. Run targeted validation for the changed area before opening a pull request.
 
+Track planned work, deferred decisions, and implementation checklists in
+[GitHub Issues](https://github.com/microsoft/identity-spiffe/issues). Keep
+repository documentation focused on current architecture, accepted decisions,
+operational runbooks, reference material, and verified platform learnings.
+Link to an issue instead of adding an actionable `TODO` to documentation or
+source comments.
+
 Useful validation commands:
 
 ```bash

GITHUB-FEDERATION-HOWTO.md

@@ -6,8 +6,8 @@ One command (`./deploy.sh --new --github`) deploys the full stack end-to-end.
 
 **References:**
 
-- Architecture: [`docs/architecture/next-github-actions-agent-federation.md`](docs/architecture/next-github-actions-agent-federation.md)
 - Platform learnings: [`docs/platform-learnings/GitHub-Actions-Federation.md`](docs/platform-learnings/GitHub-Actions-Federation.md)
+- Productization and validation backlog: [#34](https://github.com/microsoft/identity-spiffe/issues/34)
 
 ---
 

GOOGLE-FEDERATION-HOWTO.md

@@ -6,7 +6,8 @@ One command (`./deploy.sh --new --google`) deploys the full stack end-to-end.
 
 **References:**
 
-- Architecture: [`docs/architecture/next-google-cloud-agent-federation.md`](docs/architecture/next-google-cloud-agent-federation.md)
+- Platform learnings: [`docs/platform-learnings/Google-Cloud-Federation.md`](docs/platform-learnings/Google-Cloud-Federation.md)
+- Productization and validation backlog: [#35](https://github.com/microsoft/identity-spiffe/issues/35)
 
 ---
 
@@ -139,7 +140,8 @@ SPIFFE SVID from trust domain gcp.aim.microsoft.com
     (3) JWT present with required roles, (4) RBAC policy permits path+method
 ```
 
-For the full architecture, see [`docs/architecture/next-google-cloud-agent-federation.md`](docs/architecture/next-google-cloud-agent-federation.md).
+For the identity and transport architecture, see
+[`docs/platform-learnings/Google-Cloud-Federation.md`](docs/platform-learnings/Google-Cloud-Federation.md).
 
 ---
 
@@ -234,7 +236,8 @@ Exchange trust bundles on both SPIRE servers and add a `federatesWith` entry on
 
 ## See Also
 
-- [`docs/architecture/next-google-cloud-agent-federation.md`](docs/architecture/next-google-cloud-agent-federation.md) — architecture decision record
+- [#35](https://github.com/microsoft/identity-spiffe/issues/35) — productization and validation backlog
+- [`docs/platform-learnings/Google-Cloud-Federation.md`](docs/platform-learnings/Google-Cloud-Federation.md) — identity and transport learnings
 - [`docs/runbooks/hard-won-learnings.md`](docs/runbooks/hard-won-learnings.md) — #29 (container env nuke), #30 (FIC numeric ID), #31 (MSAL FIC gap), #32 (proxy-only mode)
 - Platform learnings: Google, AWS, ServiceNow — see `docs/runbooks/`
 - [`scripts/add-google-agent.sh`](scripts/add-google-agent.sh) — Entra identity provisioning

docs/architecture/admin-governance-layer.md

@@ -110,7 +110,10 @@ The repo now demonstrates two different Layer 4 stories:
 - **BudgetBackend data plane:** risk-level blocking enforced through the SPIFFE sidecar / admin-control-plane path.
 - **Direct A2A app path:** Entra-backed custom-attribute tag matching enforced at the target app after JWT validation.
 
-Today, the direct A2A demo is still **post-token** deny, not guaranteed **token issuance** deny. The CA policy in the tenant is currently report-only, and the live blocking behavior is produced by synced Entra attribute state plus target-side enforcement.
+Today, the direct A2A demo is still **post-token** deny, not guaranteed
+**token issuance** deny. The deployment provisions an enabled high-risk Agent
+Identity CA policy, while attribute matching is produced by synced Entra
+attribute state plus target-side enforcement.
 
 This distinction matters when debugging the portal:
 - `JWT VALIDATED: Yes` + `403 CA DENIED` means the app/data-plane governance layer blocked the request after token issuance.
@@ -297,13 +300,13 @@ CA evaluation results appear in **Entra sign-in logs** — the same logs admins
 - [What If Evaluation API](https://learn.microsoft.com/en-us/graph/api/conditionalaccessroot-evaluate) enables programmatic pre-deployment validation and CI/CD integration
 - [CA optimization agent](https://learn.microsoft.com/en-us/entra/security-copilot/conditional-access-agent-optimization) scans for unprotected agent identities and recommends policies
 
-## Implementation Phases
+## Current Implementation Boundary
 
-| Phase | Scope | Timeline | Cost |
-|---|---|---|---|
-| 1 | Token-time CA on agent tokens | **In production** (1K+ customers) | Minimal — register as Entra Agent ID constructs |
-| 2 | Data-plane CA in sidecar | Q1 FY27 | Moderate — evaluation client, caching, claims challenge |
-| 3 | Unified visibility + What If | Q2 FY27 | Moderate — portal integration, bidirectional policy awareness |
+The repository combines real token-time Agent Identity CA with prototype
+post-token risk and tag enforcement. Generic application and service-principal
+filter evaluation, claims-challenge integration, and unified What If
+visibility are not complete. That work is tracked in
+[#31](https://github.com/microsoft/identity-spiffe/issues/31).
 
 ## Related