affaan-m/ECC · error · Error

Refusing unverified ownership from install-state at ${plan.i

Error message

Refusing unverified ownership from install-state at ${plan.installStatePath}: operation identity does not match the current plan for ${destinationPath}.

What it means

Thrown by readOwnedDestinations when a state operation whose destination is also in the current plan fails operationIdentityMatches. The identity check compares kind, moduleId, sourceRelativePath, strategy, and scaffoldOnly between the recorded operation and the planned operation for the same destination. A mismatch means the file at that destination was installed by a different operation than the current plan intends, so the state's ownership claim does not transfer and ECC refuses to treat the file as owned.

Source

Thrown at scripts/lib/multi-harness-setup.js:167

  assertPriorInstallStateMatchesPlan(state, plan);
  const plannedByDestination = new Map(plan.operations.map(operation => [
    canonicalPath(operation.destinationPath),
    operation,
  ]));
  const destinations = new Set();
  for (const operation of state.operations || []) {
    if (operation.ownership !== 'managed') {
      throw new Error(
        `Refusing to trust non-managed ownership from install-state at ${plan.installStatePath}.`
      );
    }
    const destinationPath = operation.destinationPath;
    assertWithinTrustedRoot(destinationPath, plan.targetRoot, 'trust install-state ownership');
    const canonicalDestination = canonicalPath(destinationPath);
    const plannedOperation = plannedByDestination.get(canonicalDestination);
    if (!plannedOperation) continue;
    if (!operationIdentityMatches(operation, plannedOperation)) {
      throw new Error(
        `Refusing unverified ownership from install-state at ${plan.installStatePath}: `
        + `operation identity does not match the current plan for ${destinationPath}.`
      );
    }
    const currentFingerprint = fingerprintFile(destinationPath);
    if (
      !currentFingerprint.exists
      || !/^[a-f0-9]{64}$/i.test(operation.contentSha256 || '')
      || currentFingerprint.sha256 !== operation.contentSha256.toLowerCase()
    ) {
      throw new Error(
        `Refusing unverified ownership from install-state at ${plan.installStatePath}: `
        + `content digest does not match ${destinationPath}.`
      );
    }
    destinations.add(canonicalDestination);
  }
  return { destinations, stateFingerprint: validatedFingerprint };

View on GitHub (pinned to 01e15490f0)

Solutions

  1. Compare the state operation's kind/moduleId/sourceRelativePath/strategy/scaffoldOnly against the planned operation to see which field drifted.
  2. If the change is legitimate (upgrade/profile switch), remove the install-state and re-run the preview so ownership is re-established for the new operation identity.
  3. Pin the ECC version/profile to match the one that wrote the state if you need to preserve ownership.
  4. Confirm sourceRoot passed to createManagedPlan matches the original install.

Example fix

// before: original op had strategy:'copy', plan now has strategy:'merge-json' for same dest
// state op: { kind:'copy-file', moduleId:'m', sourceRelativePath:'a', strategy:'copy', scaffoldOnly:false }
// plan op:  { kind:'merge-json', moduleId:'m', sourceRelativePath:'a', strategy:'merge-json', scaffoldOnly:false }
readOwnedDestinations(plan); // throws [287]

// after: re-record ownership for the new operation identity
fs.rmSync(plan.installStatePath, { force: true });
const plan2 = await createMultiHarnessPlan(req);
await applyMultiHarnessPlan(plan2);
Defensive patterns

Strategy: validation

Validate before calling

const fs = require('fs');
const IDENTITY = ['kind','moduleId','sourceRelativePath','strategy','scaffoldOnly'];
function assertStateOperationsMatchPlan(statePath, plan) {
  if (!fs.existsSync(statePath)) return;
  const state = JSON.parse(fs.readFileSync(statePath, 'utf8'));
  const byDest = new Map(plan.operations.map(op => [op.destinationPath, op]));
  for (const op of state.operations || []) {
    const planned = byDest.get(op.destinationPath);
    if (!planned) continue;
    for (const f of IDENTITY) {
      if (op[f] !== planned[f]) {
        throw new Error(`Operation identity drift for ${op.destinationPath}: ${f} is '${op[f]}' in state vs '${planned[f]}' in plan.`);
      }
    }
  }
}
assertStateOperationsMatchPlan(plan.installStatePath, plan);

Type guard

function operationIdentityMatches(stateOperation, plannedOperation) {
  return ['kind','moduleId','sourceRelativePath','strategy','scaffoldOnly']
    .every(f => stateOperation[f] === plannedOperation[f]);
}

Try / catch

try {
  await applyMultiHarnessPlan(plan);
} catch (err) {
  if (/operation identity does not match the current plan/.test(err.message)) {
    fs.rmSync(plan.installStatePath, { force: true });
    const fresh = await createMultiHarnessPlan(plan.request);
    await applyMultiHarnessPlan(fresh);
  } else throw err;
}

Prevention

When it happens

Trigger: Fires when operationIdentityMatches(operation, plannedOperation) returns false for a destination present in both state and plan. Happens when the ECC catalog/version changed the source file, moduleId, install kind, or strategy for the same destination path between the original install and the current run; when a profile change remaps a destination to a different module; or when the state is from a different profile/selection that happened to target the same path.

Common situations: Upgrading ECC and re-running install where a file's source module/strategy changed; switching Kimi profiles (e.g., core -> developer) where the same destination is now sourced differently; a custom sourceRoot changing sourceRelativePath; running install after manually moving files that the state still references.

Related errors

AI-assisted analysis of affaan-m/ECC@01e15490f0 (2026-08-13). Data as JSON: /api/errors/f12d3720bf6e131e. Report an issue: GitHub.