Issue 215 Manifest-Driven Update Grill Status

Scope and authority

Fix issue 215 and optimize update, including persistent installation/validation caches and signed Turbo reuse across branches, worktrees, trusted PRs and CI. The user explicitly rejects hard performance acceptance limits.

All design questions are answered. The complete persisted understanding is ready for final grill closure; no specification or implementation is yet approved.

• Decision log.
• Update safety/performance research.
• Shared-cache access research.
• Inherited issue 197 requirements.
• Latest shared verification policy.

Current Round

• Round: R5 (confirmed closure and direct planning handoff).
• Current frontier: empty.
• Shared-understanding confirmation: approved explicitly by the user on 2026-09-16.
• Auto-pinning defaults: not authorized.
• Domain-modeling: final consistency pass complete; adopted/desired state, installation/result identity, cache eligibility, validation completeness, trust and storage/performance limits remain distinct.
• Brainstorm: rerun after Q11 expanded the boundary to remote/Turbo reuse. Current trust policy, provider evidence and complete input identity ground this frontier.
• All supplied answers Q1–Q13 have been processed independently and persisted. No design decision remains open.

Branch Dashboard

Percentages indicate requirements closure, not implementation progress. All branches are closed after explicit confirmation of the full shared understanding.

Accepted requirements

Selection, ownership and safety: Q1–Q3

• Compare previous/target baseline inventory and include settings/workspace changes.
• Inspect known managed paths directly to detect missing files, edits and drift.
• Ignore status does not establish ownership; preserve repository-authored content and verifier references.
• Shared desired-state decisions across scaffold/update/check.
• Construct a complete isolated Validation Candidate; allow bounded expansion to affected workspaces and required dependencies.
• Prune irrelevant evidence/runtime trees before traversal. No silent whole-repository fallback.
• If complete/contained inputs still cannot be established, block dependent publication with an actionable error.
• Preserve disabled dependency lifecycle scripts, confined execution/application, cleanup, verified recovery and receipt authority.
• Lint findings warn. Operational failures block dependent adoption; completed independent work remains truthfully recorded.

Reuse and cache lifecycle: Q4,Q7–Q9,Q11–Q13

• Persistent caches are included now; the proposal to defer them was rejected.
• Reuse Prepared Installations and completed Validation Results when their complete relevant identity matches.
• Replay warnings/findings. Operational failures cannot become cached success.
• Recheck current-worktree tool readiness, managed state and ownership.
• Share matching local entries across worktrees/repositories, outside consumer repositories.
• Q11 supersedes Q8's proposed local-only limit: Turbo remote reuse across branches, worktrees, PRs and CI is required.
• Bounded storage, eviction, corruption rebuild, cold fallback on unavailability, bypass/clear and hit/miss reasons are accepted.
• Concurrent producers/readers must not consume incomplete entries or share mutable candidate material.
• Credential configuration and real access must be verified without exposing secrets.
• Optional remote reuse also covers hi update internal installation/validation entries. Ordinary hi update still works without Turbo or a login through local/cold fallback.
• Reuse only when all result-affecting inputs are represented or controlled; otherwise execute affected validation fresh and explain the miss.
• An uncertain cache key is distinct from missing required candidate inputs. Fresh execution still requires the complete/contained candidate required by Q3.

Output and performance: Q5–Q6,Q10

• Preserve legacy JSON fields/meanings while exposing precise planned/completed outcomes and actionable subprocess diagnostics.
• Human progress starts before expensive work. JSON stdout remains one final document; requested progress uses stderr.
• Record useful timings and work counters.
• No maximum duration, 250 ms gate, speedup percentage, or later mandatory numeric-target approval.
• Q9 cache-storage bounds and correctness requirements are unaffected by the rejection of performance-time gates.

Current inherited Turbo trust policy

• Latest accepted verification spec supersedes older development/protected cache separation: trusted internal PRs, main and release verification may share one signed namespace when task identities match.
• Current fork verification is unsupported under the later accepted amendment and active workflow/settings. No fork credential exposure is authorized.
• Publication mutations still execute; publication credentials remain separate from cache producers.
• Portable tasks may share across compatible platforms when output equivalence is established; host-sensitive work retains capability identity.
• Branch, PR, Git SHA, checkout path or run labels must not partition identical deterministic task identities merely because their labels differ.
• Actual result-affecting environment/runtime differences must remain represented or controlled.

Sources and supersession details are in the shared-cache research report.

Technical Grounding

Final shared understanding

1. Fix issue 215 without losing project-owned content or weakening lifecycle validation.
2. Derive exact managed changes from manifest/baseline inventory, project inputs and actual file state. Select and prune validation inputs before copying.
3. Cache prepared installations and completed validation independently, replay findings and recheck live readiness/ownership.
4. Share eligible signed Turbo and updater entries across local repositories/worktrees, branches, trusted PRs and CI. Remote updater transport is optional; local/cold operation remains available.
5. Use complete content/tool/runtime/environment identity. Freshly validate uncertain reuse; block publication if the candidate itself cannot be made complete/contained.
6. Keep caches disposable, bounded and safe for concurrent use, with automatic recovery, bypass/clear and visible hit/miss reasons.
7. Verify credential/signing access through actual cross-context artifact evidence. Preserve fork/publication trust boundaries.
8. Preserve JSON compatibility, distinguish planned/completed changes and retain subprocess diagnostics. Provide early human progress, optional JSON stderr progress and useful timings without hard performance acceptance limits.

Live reasoning view

Baseline + manifest + project inputs + actual managed content
                    ↓
               Scaffold Plan
                    ↓
     Complete, bounded Validation Candidate
                    ↓
       installation / validation cache lookup
          ├─ eligible matching entry → reuse
          └─ miss or uncertain key  → execute fresh
                    ↓
       confined apply → truthful result

Cache transport: shared local + optional signed remote
Eligible contexts: repositories / worktrees / branches / trusted PRs / CI
Current-worktree readiness and owned state: checked every invocation

This is a derived view of Q1–Q13. No unanswered requirement is introduced here.

Glossary

Terms

• Baseline: selected version of Harness-managed scaffold content and contribution definitions.
• Scaffold Manifest: recorded adopted scaffold state and ownership evidence.
• Managed Artifact: artifact whose obligations follow recorded ownership and the desired Scaffold Plan.
• Context Plan: neutral per-scope contribution intent before paths/writes.
• Scaffold Plan: desired files, links, dependency/configuration changes and ownership.
• Validation Candidate: isolated proposed repository state used to verify an update.
• Prepared Installation: reusable dependency/toolchain state for one resolved installation context, including required approved patches.
• Validation Result: findings/completion evidence for a candidate under a particular validation context.
• Cache Entry: disposable stored derived content/evidence considered for reuse when complete input identity matches.

Relationships and axioms

• Context Plan feeds Scaffold Plan; Scaffold Manifest records adoption.
• Validation Candidate includes required validation context beyond owned writes.
• A source edit may invalidate Validation Result while retaining Prepared Installation reuse.
• Cache entries do not establish current-worktree readiness, applied writes or publication by themselves.
• Ignore status is not ownership authority; planned changes are not completed writes.
• Turbo task artifacts and updater cache entries retain separate contracts; Q12 accepts optional remote sharing for both.

Resolved ambiguities

• “Everywhere” explicitly includes remote Turbo contexts; trusted access boundaries remain inherited.
• “Tokens” includes short-lived OIDC access and independent artifact-signing authority. Static legacy secret names are not the active CI access path.
• “No hard limits” applies to performance acceptance, not the accepted cache storage/eviction requirement.
• “Cache hit” must distinguish declared remote enablement, Actions-restored local hits, and proven remote artifact restoration.
• Dynamic configuration can depend on inputs beyond package manifests; Q13 requires complete represented/controlled inputs for reuse, otherwise fresh validation.

Evidence and remaining validation

• Recent main CI: OIDC/cache setup succeeds; remote enabled; 15/16 tasks cached. Selected PR: setup succeeds; remote enabled; 0/16 cached. These summaries do not establish remote-versus-restored-local hit origin.
• Current local session has no observed Turbo credentials/signing key or known login/link files. Local-to-CI access is not yet proven.
• Provider OIDC policy breadth, token permissions, writer membership and Blacksmith isolation remain unverified.
• Require later artifact-specific authenticated read/write/restoration and relevant-input invalidation evidence across eligible contexts.
• Full updater benchmark is still blocked by local packaged-asset/dependency issues; measurement is diagnostic, not a hard performance gate.
• Actual macOS alias/fixture reproduction, ignored/untracked verifier preservation and scaffold→check consistency remain delivery verification.
• Source research retains 52 GB delivery data / 15 GB after current exclusions; no copied-byte counter or full-command speedup is claimed.

Parked, rejected and deferred

• Rejected: defer persistent caches; local-only Turbo scope; hard performance thresholds and mandatory numeric-target approval.
• No new user-parked branch.
• Exact module/files, backend integration mechanics and reversible task decomposition belong to planning.
• A need for a new remote service or changed fork/publication trust would require another explicit decision.
• Release/provider mutation is outside the active requirements interview.

Next route

The user explicitly approved this shared understanding and requested: “dont compile into a spec. encode it directly as is into create-plan”. Requirements are closed at 100%; no open or parked branch remains. The approved decisions and glossary in this status/log are the requirements authority for the direct execution plan. Do not create SPEC.md or project provider Tasks in this planning run. Remaining runtime/provider work is delivery verification, not a claim that access or implementation is complete.