Improve what-happened fallback responses · Entire

Improve what-happened fallback responses

0975fbe→main·

pfleidi·2mo ago·1 file·+59 added/-9 removed

Sessions

e0814f45fcd4View transcript

[?
I have added a new skill to plugins/entire/skills/what-happenedCodex·GPT-5.5·2 steps](/content/gh/entireio/skills/session/019dc0d3-6b22-7052-b168-4487a38e0f4d#timeline-e0814f45fcd4/index.html)

Changes

1

11 unmodified lines

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
3 unmodified lines

35
36
37
24
38
39
40
41
42
43
13 unmodified lines

57
58
59
44
60
61
62
63
64
65
66
30 unmodified lines

97
98
99
81
82
100
101
102
103
104
26 unmodified lines

131
132
133
115
134
135
136
137
24 unmodified lines

162
163
164
146
147
165
166
167
168
169
170
5 unmodified lines

176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
164
206
207
208
209
14 unmodified lines

224
225
226
185
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244

11 unmodified lines

Use this skill when the user wants a provenance-focused explanation for a code block.

## Response Format

Begin the first response to this skill invocation with the line:

`Entire What Happened:`

followed by a blank line, then the content.

- Apply the header to the **first response of the invocation only.** Do not re-print it on follow-up turns within the same invocation (e.g. after the user disambiguates a snippet match).
- Do **not** include the header on unresolved-input responses (e.g. snippet not found,
  ambiguous snippet, invalid path or range). If the target code was resolved but no
  checkpoint-backed context exists, still use the header and clearly label the answer as
  current-code fallback analysis rather than a checkpoint summary.

Supported inputs:

- `path:start-end`

Find the most recent change blocks matching the user's target lines, list the matching
commit hashes and checkpoint state, then summarize why each block was changed using the
cheapest reliable context available.
cheapest reliable context available. When checkpoint-backed context is unavailable, still
explain what the current code does as an explicit fallback and clearly mark that explanation
as not checkpoint-backed.

## Rules

- a checkpoint is referenced but is unavailable locally or remotely
- a checkpoint is available, but full transcript expansion failed
- the code is untracked, uncommitted, or otherwise has no committed history

8. Keep the final explanation concise and block-focused. Do not summarize unrelated parts
of the file.

9. Keep the final explanation concise and block-focused. Do not summarize unrelated parts
of the file.

## Workflow

- git blame --porcelain -L <start>,<end> -- <path>
```

If the command fails because the file is untracked, stop and say that the file is not tracked
by git, so there is no committed history to trace.
If the command fails because the file is untracked, mark the whole target range as having no
committed history and continue to fallback code behavior analysis.

If blame reports an uncommitted pseudo-commit such as all zeroes or `Not Committed Yet`, mark
those ranges as local uncommitted changes and do not run `entire explain` for them. If other
 26 unmodified lines

failed lookup; it removes branch/depth limits and may be slow.

If this command fails, do not scan raw session files. Use `git show --no-patch` for commit
metadata, mark the explanation as commit-only context, and report that Entire transcript
metadata, mark the range for fallback code behavior analysis, and report that Entire transcript
lookup failed. Include the command error only if it helps the user fix the issue, such as
authentication or missing remote configuration.

- why this block changed
- any constraint, bug, edge case, or refactor pressure that caused the final code

If the commit has no checkpoint ID, use commit-level context and the code block itself, clearly
marked as "commit-only context; no Entire checkpoint was referenced."
If the commit has no checkpoint ID, use commit metadata only for provenance and mark the range
for fallback code behavior analysis. Clearly state "no checkpoint-backed summary; no Entire
checkpoint was referenced."

If a checkpoint ID is present but `entire explain --checkpoint` cannot load it, keep the
checkpoint ID in the answer and say "checkpoint <id> was referenced, but the checkpoint was

...

Map each unique commit explanation back to every target range blamed to that commit.

### 4. Add fallback code behavior analysis when needed

For any resolved range without a checkpoint-backed explanation, still answer what the current
code does. This applies when:

- the file is untracked
- the range is locally uncommitted
- no checkpoint is referenced for the commit
- the checkpoint is referenced but unavailable
- transcript lookup or expansion fails
- any other provenance command fails after the target code was resolved

Use only source-backed analysis:

- Read the target block and the smallest necessary surrounding scope, such as the enclosing
function, type, imports, or constants.
- Use `rg` to inspect direct call sites or definitions only when the block cannot be understood
from local context.
- Explain observable behavior, inputs, outputs, side effects, and important branches.
- Do not present this as historical intent, checkpoint rationale, or an agent transcript summary.
- State what cannot be known from current code alone.

## Response format

Start with a short provenance summary:

````text
What Happened:
Entire What Happened:

Matches
- <path>:<start>-<end> -> commit <sha> | checkpoint <id>

```

Then give one short section per distinct matching block:
For checkpoint-backed ranges, give one short section per distinct matching block:

```text
Why
- <path>:<start>-<end>: <2-4 sentence explanation of why this block changed last time>
```

For ranges without checkpoint-backed context, use this separate section instead:

```text
Current-code fallback (not checkpoint-backed)
- <path>:<start>-<end>: <2-4 sentence explanation of what the current code does, plus any
  limits on what can be inferred without checkpoint history>
```

Snippet guidance:

- Prefer the exact matched lines from the file.
````