Deferred work

Measure real Cloud Run observer adoption after #891

What: Evaluate one consenting internal workflow using the exact execution observer and measure classification usefulness and replaced custom code.

Why: The two required neutral consumers prove reusable contracts; they do not establish production value or an acceptable Unknown rate. Pros: Exposes missing evidence and practical caller decisions before broader adoption; gives honest outcome measurements. Cons: Needs an application owner, separately authorized provider access and a real deployment window; synthetic fixtures cannot supply that evidence.

Context: Start with the #891 execution-observation design. Preserve full parity, exact identity, budget and zero mutation. Measure safe diagnostic frequencies, actual custom implementation/test lines replaced, and caller actions after Unknown. No automatic recovery is added to the package.

Effort: Human M / agent S, estimated; owner and provider access dominate elapsed time. Priority: P3. Depends on / blocked by: Accepted exact-version evidence manifest, working packaged observer, named adopter and separately authorized cloud reads/release. Deferred by autoplan CEO C6; this adds no #891 acceptance gate.

Coverage storage: remote/team retention follow-up

• What: Evaluate an optional remote archive/export integration only after an adopter needs evidence beyond the user-local managed history. Why: Local byte/age retention cannot promise durable team access. Pros: Could preserve selected release or investigation evidence across machines. Cons: Adds credentials, transfer cost, remote retention and deletion ownership. Context: The coverage storage design keeps ordinary upgrades local, preserves current reports and exposes explicit pin/restore; existing uploads remain available. Effort: L human / M agent, estimated. Priority: P3. Depends on: Shipped local lifecycle plus an identified adopter/owner and concrete remote retention requirement. Deferred in CEO C6; no remote service is part of this delivery.

Metadata-only deployment-name linter (#890 follow-up)

What: Consider an offline deployment-manifest linter built on the candidate inspector design after concrete adopter demand. Why: Hosts could check supplied environment-name inventories without resolving secret values or duplicating AppSurface spelling rules. Pros: Reuses the pure candidate contract and could catch deployment policy mistakes earlier. Cons: Introduces manifest grammar, inventory trust/casing, complete-path selection and application policy contracts that #890 deliberately leaves to callers. Context: #890 delivers names only and two neutral public-package examples. First gather an adopter's manifest and policy; do not treat generated candidates as proof of presence, ownership or complete aggregate composition. Effort: L human team / L agent assistance (unmeasured; new tool and policy surface). Priority: P3. Depends on / blocked by: Shipped #890 API, verified adopter need and a separately reviewed inventory/policy contract. Deferred by autoplan CEO C5; no linter implementation in #890.

DevAuth persona fixture activation (#772)

Host-owned durable or multi-process reference example

What: Consider a durable or multi-process fixture example only after a concrete adopter demonstrates that the process-local #772 design is insufficient.

Why: A persistence example could explain transactional ensure, scenario-key uniqueness and cross-process consistency while preserving host ownership.

Pros: Shows how a real host preserves one scenario and completed work across processes and restarts.

Cons: Adds a persistence provider, credentials, cleanup, lifecycle and failure policy to maintain.

Context: The planned delivery will prove one synthetic candidate with independent labeling/review progress in a single host process. It resets on restart and makes no durable or cross-process guarantee. Start with the execution plan and the adopter's concrete failure before choosing storage. This follow-up adds no persistence work, telemetry or schedule to #772.

Effort: L for a human team / M with agent assistance.

Priority: P3.

Depends on / blocked by: Concrete adopter evidence; a host-selected persistence engine; scenario-key uniqueness and transaction design; an independently reviewed failure/recovery policy.

Server-pushed RazorWire dialogs (#828 follow-up)

• What: Design explicit server-pushed dialog commands after request-scoped #828 dialogs are adopted. Why: A live stream has no initiating request or current form owner, so the request/flow token contract from #828 cannot be reused unchanged. Pros: Supports genuinely asynchronous attention when an application has a user need. Cons: Adds replay, authorization, interruption, and multi-tab lifecycle decisions. Context: #828 intentionally supports only response-owned dialogs; keep hub replay and automatic presentation outside its first release. Effort: L human team / M CC + gstack. Priority: P3. Depends on / blocked by: #828 adoption evidence and a concrete server-initiated use case.

Durable role-pair retirement after #823

• What: Design an explicit, reviewed procedure to retire or narrow one PostgreSQL Durable role pair without treating omission from the complete manifest as authorization to remove it. Why: #823 makes enrollment safe but a decommissioned lane otherwise leaves stale grants and policy targets. Pros: Closes the credential lifecycle while preserving the fail-closed manifest contract. Cons: Requires deployment-use proof, a lock-protected exact removal, post-removal ACL/policy and surviving-lane tests, and a coordinated operator window. Context: Start with the #823 design and plan; first prove no active host or secret uses the pair, then review the removal action separately. Effort: M (human: 1–2 days / agent assistance: several hours). Priority: P2. Depends on / blocked by: #823 enrollment release and an actual pair retirement or profile-narrowing need.

File-declared secret reference follow-ups (#807)

• What: Add a compile-only secret-reference preflight that validates type graphs, file layers, mappings, provider compatibility, and environment aliases without resolving payloads. Why: Effective audit intentionally performs the same remote reads as runtime, while deployment tooling may need a zero-read readiness check. Pros: Safer CI and deployment review, reusable compiled-plan evidence, and no IAM/network dependency for structural validation. Cons: Adds a second execution mode and public naming/reporting contract that must not drift from runtime semantics. Context: #807 creates one value-free compiler and defers compile-only presentation; build this only by consuming that compiler rather than adding another parser. Depends on / blocked by: Stable #807 plan/result contracts and adopter evidence for the command or API shape.
• What: Consider conditional secret activation after static enabled has shipped and been used. Why: Some services may eventually need environment- or feature-dependent secret requirements. Pros: Can model optional capabilities without duplicating configuration roots. Cons: Introduces expression evaluation, dependency ordering, explainability, and new fail-open risks. Context: #807 intentionally supports only a static boolean so provisioning state is deterministic and locally validatable. Depends on / blocked by: A concrete adopter case that cannot be handled by separate environment files or roots.
• What: Design object-, collection-, dictionary-, and collection-item secret destinations as a separate binding extension. Why: The first release supports only scalar Secret<T> destinations and rejects shapes whose merge, path, and validation semantics are not yet defined. Pros: Broadens provider-backed configuration beyond scalar credentials. Cons: Greatly expands path identity, atomicity, redaction, allocation, and audit traversal behavior. Context: Do not weaken #807's scalar gate or infer behavior from ordinary JSON merge rules. Depends on / blocked by: Stable scalar adoption plus a real provider/consumer model requiring structured payloads.
• What: Add a version-aware LocalSecrets inline resolver only if the local store gains a truthful version contract. Why: #807 cannot satisfy a pinned declaration with an unversioned local value without lying about version intent. Pros: Gives local development providerless parity with remote providers. Cons: Requires storage schema, rotation, provenance, and migration decisions in LocalSecrets. Context: LocalSecrets remains a supported sensitive lower-object source in #807, but does not claim an inline descriptor. Depends on / blocked by: A LocalSecrets version model and compatibility/migration design.
• What: Revisit asynchronous secret resolution, cancellation, and optional parallel providerless probing. Why: The existing configuration API is synchronous, so #807's per-root deadline is cooperative and cannot preempt a non-conforming provider. Pros: Hard cancellation, better startup latency with many providers, and more natural cloud SDK integration. Cons: Changes the configuration activation API and makes deterministic ambiguity/error ordering harder. Context: Built-in providers must cap synchronous calls to the supplied remaining budget; explicit provider remains the production latency recommendation. Depends on / blocked by: A broader asynchronous configuration API proposal and measured startup latency.
• What: Consider provider-owned refresh or rotation integration without placing payloads in the composition plan. Why: Long-lived applications may eventually need fresh secret values after startup. Pros: Supports rotation without host restart. Cons: Changes Secret<T> immutability, validation timing, cache ownership, and audit snapshot semantics. Context: #807 deliberately resolves immutable wrapper values and preserves existing provider cache lifetimes; no background service is introduced. Depends on / blocked by: A concrete rotation SLO and a separate lifecycle/security review.

Typed Work definition adoption follow-up (#800)

• What: Review two independent definition migrations, or review six months after release if fewer migrations exist, before adding more convenience APIs. Why: #800 proves contract consistency and preserved runtime behavior; faster onboarding and fewer real-user errors remain unmeasured. Pros: Grounds later API work in observed friction and helps the parent adoption rail compare correct registration, request authoring and actual terminal completion. Cons: Requires adopter participation and cannot establish causality from a tiny sample. Context: Start with the approved design and implementation plan; record duplicated facts removed, decisions retained, authoring mistakes, cached/cold prerequisites and time to first accepted-and-processed Work separately. Line count is secondary; do not turn missing timing into a fabricated speed claim. Effort: M (human: 1–2 days / agent assistance: 2–4 hours, excluding adopter availability). Priority: P3. Depends on / blocked by: #800 release and real adopter evidence; no telemetry collection or scheduled automation is authorized by this TODO.

Named-canary snapshot follow-ups (#645)

• Consider POST exact-list batches, host-declared snapshot profiles, asynchronous jobs, or stored snapshots only if adopters show that the bounded synchronous GET /_appsurface/canaries contract is insufficient.
• Keep polling, retry/backoff, CI exit codes, and GitHub reporting in the caller/workflow follow-up tracked by #625; the AppSurface package remains a current-proof producer, not a deployment controller.
• Revisit schema versioning or a generated client only after a stable external consumer demonstrates a compatibility need.

Durable runtime operations follow-ups (#641)

• Consider broker-backed activation only when a deployment requires scale-to-zero or a provider can preserve the existing bounded IDurableRuntimePump.RunOnceAsync contract. PostgreSQL remains authoritative; polling is the recovery path and metadata-only wake hints remain optional and advisory.
• Consider an application-owned authorized operator dashboard or HTTP control surface only after an adopter identifies a real workflow that the typed health and drain APIs cannot serve. Do not add a Durable-owned endpoint or second operational timeline by default.
• Consider independently configured per-surface worker hosts when production latency evidence shows that one sequential Work/Flow/Schedule pass cannot meet a service objective. Keep the common runtime kernel and PostgreSQL claims/fences rather than adding local parallel fan-out.
• What: Consider extracting transport-neutral health and activation contracts into a package with no Durable execution-stack dependency. Why: ForgeTrust.AppSurface.Durable.Provider intentionally references the full Durable package today; a transport host therefore receives Flow, Core, and Workers transitively even if it only activates a runtime. Pros: Could reduce restore/version coupling for independently deployed activators. Cons: Adds another public package, coordinated-version policy, API baselines, and migration work before any adopter has shown the current graph is a problem. Context: The executable-contract adoption rail keeps the existing Provider boundary and enforces that public activation contracts expose no PostgreSQL, ASP.NET Core, or application types. Depends on / blocked by: An independent activator that measures the transitive graph as an adoption or deployment blocker.
• What: Consider a dedicated PostgreSQL heartbeat-maintenance principal and scheduler instead of runtime-owned opportunistic pruning. Why: Migration 0005 deliberately trusts the isolated runtime credential for all unscoped heartbeat rows; the planned retention function extends that principal with bounded stale-row deletion. Pros: Narrows deletion capability if a deployment cannot accept the existing runtime-principal blast radius. Cons: Adds a credential, rotation path, scheduler owner, deployment ordering, and failure mode for capacity-only maintenance. Context: The current design treats caller-supplied worker identity as a correctness guard, not authentication, and constrains deletion by stale cutoff, table, signature, advisory lock, and batch size. Depends on / blocked by: A concrete adopter threat model that cannot treat the runtime credential as a trusted maintenance principal.

Config-audit debug expansion follow-ups (#389)

• Consider targeted expansion of one already-known audit entry and a separately mapped or more strictly authorized debug endpoint only after operator evidence shows that the bounded report-wide expansion is insufficient. Preserve the known-entry boundary, current redaction pipeline, and explicit operator intent.

Tenant-theme selection follow-ups (#705)

• Design a separate composition contract for tenant/context pair selection together with browser-local user mode preference only when an adopter needs both. It must define first-paint order, CSP behavior, static-export limits, failure semantics, and migration guidance; do not let two document-provider opt-ins silently compose.
• Revisit asynchronous selection only when a supported host context cannot be resolved before rendering without I/O. Keep tenant lookup and caching upstream from the Web rendering path by default.
• Consider an explicit compatible-provider/decorator marker only if enterprise adopters demonstrate that the strict custom-provider escape path blocks legitimate instrumentation or resilience wrappers.

JavaScript class harvesting follow-ups (#301)

• Define derived-class and inherited-member documentation semantics only when a package author needs them. The follow-up must decide source identity, rendered hierarchy, stable anchors, search behavior, and diagnostics before locally declared derived-class members can be harvested; do not partially publish an inheritance model.

Fine-grained harvest observatory follow-ups (#343)

• What: Consider development-only file/relative-path progress labels only after a real maintainer workflow proves aggregate parser phases and counts are insufficient. Why: Source identity materially expands the privacy boundary without improving the default #343 proof surface. Pros: Gives a future troubleshooting workflow more local context. Cons: Requires explicit opt-in, operator authorization, and a fresh redaction review. Context: #343 deliberately publishes only phase, source-unit counts, documents, and a rolling built-in rate; source identity must never become the default live-stream payload. Depends on / blocked by: Evidence from an adopter that aggregate progress is insufficient.
• What: Consider a public optional custom-harvester progress contract after an external IDocHarvester adopter supplies a concrete integration. Why: The internal package-owned session solves today’s need without locking an unproven callback API. Pros: Could eventually give ecosystem harvesters parity. Cons: Commits compatibility, publication bounds, redaction, and versioning rules for a public contract. Context: #343 keeps custom harvesters status-only. Depends on / blocked by: A real external adopter and separate public-API/privacy review.
• What: Consider a historical rate chart or event-history stream only if current-state observability proves inadequate for a documented operational workflow. Why: A maintainer may later need retrospective analysis rather than current-state proof. Pros: Enables trend investigation. Cons: Turns _harvest toward a log viewer and competes with its bounded state/replay design. Context: #343 uses a 250 ms coalesced snapshot and existing replay rather than per-file events. Depends on / blocked by: A documented operator workflow current state cannot support.
• What: Consider an application-owned diagnostics dashboard or alert only when an adopter identifies a durable operational owner and service objective. Why: The package should expose proof, not become a telemetry backend. Pros: Could support sustained production operations when there is an owner. Cons: Adds hosting, retention, alerting, and operational cost unrelated to #343. Context: The observatory remains source-backed and in-process. Depends on / blocked by: An adopter-defined owner, objective, and operational design.

Coverage-proof follow-ups (#674)

• What: Add a synthetic multi-project or multi-target packaged-consumer graph to the semantic coverage proof. Why: The owned Smoke.Tests sentinel will catch exact-project collection and raw-to-merged loss, but not every graph-specific regression. Pros: Covers multiple application assemblies, fan-in shape, and framework-specific output paths. Cons: Extends the fixture and release runtime beyond the smallest #674 guard. Context: Land only after the canonical manifest-bound sentinel has run reliably; use a demonstrated regression or adopter graph to choose the shape. Depends on / blocked by: The #674 semantic proof and observed need.
• What: Extract or formalize a shared runner/integration classifier only if evidence shows the CLI and diagnostic classification need the same contract. Why: A separate external classifier can drift from the VSTest-only CLI contract. Pros: One tested meaning for runner, direct coverlet package identity, and compatibility errors. Cons: Can expand coverage-engine scope or introduce a cross-project dependency without a real fault. Context: #674 keeps the external classifier diagnostic-only and does not change VSTest/MTP support. Depends on / blocked by: A current classified reproduction showing a CLI contract mismatch.

Release provenance follow-up (#798)

Portable verification and retention beyond Actions

What: Evaluate signed portable release evidence and longer-lived storage only after an adopter requires verification outside the trusted Actions run.

Why: The #798 proof ends at the validated pre-push input and depends on retained Actions artifacts; it does not authenticate outside observers or survive artifact expiry.

Pros: Independent consumer verification and a longer operational audit window.

Cons: New signing identity, storage lifecycle, authorization, and remote-package semantics.

Context: Start from the #798 implementation plan and the existing producer/host/aggregate binding. Built-in GitHub attestations can carry provenance, but do not replace proving the restored payload used by each host. The #806 template design reuses this trusted Actions boundary and keeps portable signing/storage here; a local template receipt alone does not authenticate an outside observer.

Effort: L human / M agent Priority: P3 Depends on: #798 acceptance evidence and a demonstrated need beyond current retention/trust boundaries.

Hang-diagnostics follow-ups (#815)

• What: Design a Microsoft.Testing.Platform hang-diagnostics policy after AppSurface supports MTP coverage execution. Why: #815's no-dump blame switches and Sequence.xml are VSTest-specific; pretending they work for MTP would produce false diagnostics. Pros: Eventually gives MTP adopters the same owned, bounded operator evidence. Cons: Requires a separate runner, artifact and timeout contract with its own integration fixtures. Context: Keep the #815 collector and msbuild VSTest release explicit about this boundary. Depends on / blocked by: A supported MTP coverage path and at least one adopter reproduction.
• What: Evaluate adaptive hang thresholds from observed healthy per-test durations. Why: #815's fixed per-test VSTest timeout can terminate a legitimate long test; the documented manual and longer-budget overrides are the immediate escape paths. Pros: A measured policy could reduce false terminations across varied suites. Cons: Historical timing can be stale, incomplete or misleading and would add configuration and state. Context: Preserve the approved --watchdog fail default and collect controlled fixture plus adopter timing data before changing policy. Depends on / blocked by: Release measurements and recurring long-test failures across supported consumers.

Logical configuration-key follow-ups

• What: Add a source analyzer and optional codemod for legacy dotted AppSurface configuration-key call sites. Why: Runtime diagnostics can identify executed paths, but they cannot prove that every attribute, direct read, audit registration, provider mapping, and dormant branch has migrated. Pros: Gives maintainers a compile-time inventory and automates safe . to : replacements. Cons: The analyzer would freeze grammar and API assumptions too early if built before the typed key and migration diagnostics stabilize. Context: The logical-key contract deliberately keeps only one permanent colon syntax and uses bounded compatibility input; the analyzer should consume the final parser rules rather than reimplementing them. Effort estimate: L (human team) -> M with CC+gstack. Priority: P2. Depends on / blocked by: Stable AppSurfaceConfigKey, application-boundary parser, diagnostic codes, and release-train policy.
• What: Add a credentialed Google Secret Manager contract proof for explicit mappings, convention ids, versions, and exact provenance. Why: The fake transport proves AppSurface behavior but cannot prove deployed IAM, API resource validation, or response-name behavior. Pros: Catches provider drift before a release and validates the exact native-resource contract. Cons: Requires a dedicated project, credential rotation, cleanup, cost controls, and a trust-boundary design for CI. Context: Keep the default provider suite deterministic and value-safe; run the live proof as a separate protected release verification rather than enumerating unclaimed secrets. Effort estimate: M (human team) -> S with CC+gstack. Priority: P2. Depends on / blocked by: Stable Google codec/resource-claim contract and approved CI credential design.

Issue 866 follow-ups — deferred by autoplan

Skoolit consumer implementation/adoption is separate future work in the open case #1259. AppSurface SDK implementation, testing, coverage, and the draft PR remain in scope independently.

C6: asynchronous preparation hooks

What: Consider an async hook family only after a named consumer requires awaited setup. Why: It could support external setup without unsupported async-void callbacks; current Skoolit graph selection is synchronous. Pros: Explicit cancellation and awaited ownership. Cons: More overloads and lifecycle branches. Context: The configured testing design keeps synchronous actions. Gather the adopter's awaited operation before designing another API. Effort: human L / agent M Priority: P3 Depends on: issue 866 adoption and concrete async demand.

C7: provider-specific replacement guidance

What: Gather multiple provider-specific replacement needs before considering a general abstraction. Why: ConfigureContainer can override service-collection descriptors; stronger guarantees require real provider contracts. Pros: Clear consumer guidance across providers. Cons: Provider coupling and maintenance. Context: The configured testing design preserves default-provider and Autofac semantics; it does not promise universal last-wins behavior. Start with two concrete adopter cases. Effort: human L / agent M Priority: P3 Depends on: current provider proof and at least two consumer needs.

Documentation alias publication preflight (#176 follow-up)

• What: Consider a publish-time catalog validation command only when an adopter needs to reject an invalid alias before deploying. Why: #176 validates once in the host; a release pipeline may eventually need earlier feedback. Pros: Could reduce deploy-time configuration mistakes. Cons: Adds a public CLI contract and risks parser/verification drift. Context: Reuse the #176 alias design and implementation plan, with the same normalization, duplicate, visibility and verified-target rules; do not build another parser. Effort: M human (1 day) / S agent (2–3 hours). Priority: P3. Depends on / blocked by: #176 runtime adoption and a concrete publication workflow requiring offline feedback. Deferred by autoplan CEO C5; no command implementation in #176.

Evidence readiness (#867)

Multi-resource readiness composition

What: Consider multi-resource dependency graphs or arbitrary asynchronous readiness predicates only after a concrete adopter demonstrates that the one-resource API cannot serve its test/evidence flow.

Why: Avoid each adopter rebuilding needed coordination while keeping the first Evidence readiness design small.

Pros: A proven second use case could establish reusable ordering and failure semantics.

Cons: Adds cancellation, concurrency, ownership and public API commitments that the current single-resource case does not justify.

Context: #867 places a BCL-only HTTP probe beneath existing Aspire testing and EvidenceHost adapters. Its C6 expansion is deliberately deferred; start with an adopter's concrete unsatisfied flow and the existing native health APIs. This item adds no wait graph, hosted metrics or bootstrap relocation to #867.

Effort: L human team / M with agent assistance.

Priority: P3.

Depends on / blocked by: #867 adoption evidence and a concrete multi-resource requirement, with separately reviewed ownership/cancellation semantics.

Handoff consumer feasibility (#869 follow-up)

• What: After a supported coordinated package is available, inventory the actual downstream authority/ledger writers and prove their lock order with a pinned public-package executor flow. Why: The #869 framework plan proves the generic boundary; it cannot certify an application's competing writers or provider policy. Pros: Exposes implicit foreign-key/enqueue locks and confirms that the supported API replaces private SQL in a real integration. Cons: Depends on another repository's schema, release availability and consumer-owned provider/reconciliation choices. Context: Keep Skoolit #735 blocked until its separately owned package upgrade and feasibility proof pass; no consumer business logic or activation is included in #869. Effort: M human (1–2 days) / M agent (3–6 hours), estimated after schema access. Priority: P3. Depends on / blocked by: Published supported package, identified adopter/owner and actual writer audit. User approved autoplan d1a on 2026-10-14: preserve the framework-first milestone and this separately owned downstream proof.