Greptile Summary

This PR wires forensic activity events into three previously un-instrumented paths — the recovery subsystem, metadata-corruption detection, and the agent-report apply path — so post-incident RCA can reconstruct exactly what ao recover did, when a corrupt metadata file was silently renamed, and why an agent-report transition was rejected.

• Recovery (recovery/manager.ts, recovery/actions.ts): emits recovery.session_failed once per failed session in the runRecovery loop (B22) and recovery.action_failed in the recoverSession outer catch; both events carry projectId from the assessment.
• Metadata corruption (metadata.ts): emits metadata.corrupt_detected after a corrupt-JSON rename attempt, with a 200-char contentSample (B11) and a renameSucceeded flag; the summary string is built before the rename result is known, so it always reads "renamed to X" even when the rename failed.
• Agent-report (agent-report.ts): emits api.agent_report.session_not_found and api.agent_report.transition_rejected; unlike every other new event, neither includes a projectId, making project-scoped RCA queries incomplete for these paths.

Confidence Score: 4/5

Safe to merge; the new event calls are best-effort (never throw), the lock behaviour is correct, and the two small inconsistencies are cosmetic rather than functional.

The core instrumentation is well-structured and consistent with the existing activity-events infrastructure. Two minor issues exist: the metadata.corrupt_detected summary string incorrectly claims a rename succeeded in failure cases, and both api.agent_report.* events omit projectId even though every other new event supplies it. Neither breaks any runtime behaviour, but they reduce the accuracy and filterability of the forensic data this PR is specifically designed to provide.

packages/core/src/agent-report.ts and packages/core/src/metadata.ts warrant a second look for the projectId gap and the misleading summary string respectively.

Sequence Diagram

sequenceDiagram
    participant RM as runRecovery (manager.ts)
    participant EA as executeAction (actions.ts)
    participant RS as recoverSession (actions.ts)
    participant AE as recordActivityEvent

    RM->>EA: executeAction(assessment)
    EA->>RS: recoverSession(...)
    alt recoverSession throws
        RS->>AE: recovery.action_failed
        RS-->>EA: "{success:false, error}"
    end
    EA-->>RM: RecoveryResult

    alt "result.success === false"
        RM->>AE: recovery.session_failed
    end

    participant AR as applyAgentReport (agent-report.ts)
    participant MM as mutateMetadata (metadata.ts)

    AR->>MM: readMetadataRaw
    alt session not found
        AR->>AE: api.agent_report.session_not_found
        AR-->>AR: throw Error
    end
    AR->>MM: mutateMetadata(updater)
    MM->>MM: validateAgentReportTransition
    alt transition invalid
        MM->>AE: api.agent_report.transition_rejected
        MM-->>AR: throw Error
    end

    AR->>MM: mutateMetadata (corrupt path)
    alt JSON parse fails
        MM->>MM: renameSync to .corrupt-ts
        MM->>AE: metadata.corrupt_detected
    end

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
packages/core/src/metadata.ts:378-384
The `summary` field is constructed before `renamed` is set, so it always reads "renamed to X" even when the `renameSync` call fails (`renameSucceeded: false`). Since this event is specifically for RCA forensics, a summary that contradicts `data.renameSucceeded` can mislead engineers who glance at the summary without inspecting the full payload.

```suggestion
          recordActivityEvent({
            projectId: inferredProjectId || undefined,
            sessionId,
            source: "session-manager",
            kind: "metadata.corrupt_detected",
            level: "error",
            summary: renamed
              ? `Corrupt metadata for session ${sessionId} renamed to ${basename(corruptPath)}`
              : `Corrupt metadata for session ${sessionId} detected (rename failed)`,
```

### Issue 2 of 3
packages/core/src/agent-report.ts:387-392
Both `api.agent_report.session_not_found` and `api.agent_report.transition_rejected` are emitted without a `projectId`, but every other new event in this PR (`recovery.*`, `metadata.corrupt_detected`) includes one. Since `applyAgentReport` receives `dataDir`, the same `basename(dirname(dataDir))` inference used in `metadata.ts` can populate `projectId` here, making these events filterable in project-scoped RCA queries.

```suggestion
  const raw = readMetadataRaw(dataDir, sessionId);
  const inferredProjectId = basename(dirname(dataDir)) || undefined;
  if (!raw) {
    recordActivityEvent({
      projectId: inferredProjectId,
      sessionId,
      source: "api",
      kind: "api.agent_report.session_not_found",
```

### Issue 3 of 3
packages/core/src/agent-report.ts:470-473
The `transition_rejected` event is also missing `projectId`, which was just inferred above. Passing it here keeps the two `api.agent_report.*` events consistent and filterable by project.

```suggestion
      recordActivityEvent({
        projectId: inferredProjectId,
        sessionId,
        source: "api",
        kind: "api.agent_report.transition_rejected",
```

_{Reviews (1): Last reviewed commit: "feat(core): activity events for recovery..." | Re-trigger Greptile}

@harshitsinghbhandari — flagging you as a likely reviewer/owner here based on git blame of the files this PR touches:

• packages/core/src/agent-report.ts — sole-authored by you (~603 lines)
• packages/core/src/metadata.ts — top contributor (~326 lines), most-recent meaningful commits are yours
• packages/core/src/recovery/actions.ts — recently touched by you in refactor(core): storage redesign — projectId-based paths, JSON metadata #1466

recovery/manager.ts is originally @harsh-batheja's (#362), but you've been the active maintainer across the other three files. Would you be able to take this one over, or at least review?