|
504 | 504 | {"timestamp": "2026-08-02T08:03:47.540698+00:00", "skill": "learn", "action": "manual-stage:77ce859d6970", "result": "success", "detail": "Manually staged lesson 77ce859d6970 via .agent/tools/learn.py: 'When a config fix for a CI tool (linter, scanner, formatter) is verified locally before pushing, verifying against a locally-installed \"latest\" or default version of that tool is not sufficient -- CI workflows commonly pin a specific action/tool version (e.g. a GitHub Action tagged @v19) that can be substantially older than whatever installs by default locally, and newer tool versions can silently support config schema or CLI flags that the older, actually-pinned version does not. A config change that tests clean locally can still fail in real CI for this reason alone. Before trusting a local verification of a CI-tool config fix, identify the exact tool version the CI workflow actually pins (check the action\\'s own release notes or its own bundled dependency versions, often visible in error message doc-links CI itself produces) and install that exact version locally to test against, not the newest available.'", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_77ce85"}, "evidence_ids": ["2026-08-02T08:03:47.540698+00:00"]} |
505 | 505 | {"timestamp": "2026-08-02T08:04:00.461112+00:00", "skill": "learn", "action": "manual-stage:084412e4e566", "result": "success", "detail": "Manually staged lesson 084412e4e566 via .agent/tools/learn.py: \"Secret-scanning tools like gitleaks scan the full commit history range in a branch/PR by default, not just the current tree state -- a test fixture or example value that merely resembles a secret (e.g. a hardcoded hex digest used as an expected HMAC output) can trip a generic entropy detector, and even after a later commit fixes the pattern by removing the literal value, the scanner keeps flagging the earlier, now-superseded commit on every subsequent CI run for that branch, because the flagged content is still present in that commit's diff within history. This is a real, recurring category of false positive distinct from an actual leaked secret, and the correct fix is a scoped allowlist entry for the specific commit SHA(s) in the scanner's config (with `useDefault = true` or equivalent to keep the rest of the default ruleset intact) -- not editing the current file again, since the flagged content is no longer there, and not disabling the scanner or its ruleset broadly.\"", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_084412"}, "evidence_ids": ["2026-08-02T08:04:00.461112+00:00"]} |
506 | 506 | {"timestamp": "2026-08-02T08:04:10.909066+00:00", "skill": "learn", "action": "manual-stage:5f0362a3f95f", "result": "success", "detail": "Manually staged lesson 5f0362a3f95f via .agent/tools/learn.py: \"A short/abbreviated git commit SHA (e.g. from `git log --oneline` output) must never be extended into a full 40-character SHA by guessing, padding, or pattern-completing the remaining hex digits -- even when the extension is meant only for a config file (an allowlist, a pin) rather than executable code, a fabricated SHA silently fails to match anything (a security tool's allowlist entry that doesn't match the real commit provides zero actual exemption, while looking correct at a glance) or, worse, could coincidentally collide with an unrelated real commit. Always resolve a full SHA explicitly with `git rev-parse <short-sha>` and use that exact output, verified by direct comparison, before writing it into any tracked file.\"", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_5f0362"}, "evidence_ids": ["2026-08-02T08:04:10.909066+00:00"]} |
| 507 | +{"timestamp": "2026-08-02T14:51:33.099231+00:00", "skill": "learn", "action": "manual-stage:61d719978435", "result": "success", "detail": "Manually staged lesson 61d719978435 via .agent/tools/learn.py: \"When two changes bundled in the same commit are meant to work together (a feature-gating flag and the feature it gates, a deferral/rollout date and the behavior that respects it), verify they are actually consistent with each other by running the specific test that exercises that consistency together -- not just trusting each change's own isolated test coverage. A change that extends or modifies a gate without checking what depends on that gate's current state can silently ship an internal contradiction that only surfaces once something exercises both halves at once.\"", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_61d719"}, "evidence_ids": ["2026-08-02T14:51:33.099231+00:00"]} |
| 508 | +{"timestamp": "2026-08-02T14:51:33.194950+00:00", "skill": "learn", "action": "manual-stage:64d1deca2fca", "result": "success", "detail": "Manually staged lesson 64d1deca2fca via .agent/tools/learn.py: 'When removing a duplicate call site as a concurrency/correctness fix, check whether that call site actually serves two different purposes depending on which code state it runs in before deleting it everywhere -- the same fallback or retry call can be genuine duplication in one state (e.g. a single-racer scenario where the fallback target is already the racer that just failed) and the intended, necessary behavior in a different state (e.g. a multi-racer scenario where the fallback target was never itself one of the racers). Removing it unconditionally fixes the duplication bug in the first state while introducing a regression in the second; the correct fix is usually conditional on which state actually applies, not a blanket removal.'", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_64d1de"}, "evidence_ids": ["2026-08-02T14:51:33.194950+00:00"]} |
| 509 | +{"timestamp": "2026-08-02T14:51:33.276838+00:00", "skill": "learn", "action": "manual-stage:8bf6b00d2a44", "result": "success", "detail": "Manually staged lesson 8bf6b00d2a44 via .agent/tools/learn.py: 'Confirming a large batch of test failures is pre-existing and unrelated to a session\\'s own changes (via a before/after comparison) is a necessary check but not the same as understanding why the failures exist -- stopping there leaves a large, alarming-looking failure count in the record with no actual explanation. Where time allows, finishing the diagnosis by installing missing dependencies one at a time and re-running (watching the count drop) can turn \"pre-existing, unrelated, unexplained\" into \"pre-existing, unrelated, and here is exactly why, with zero project-level fix needed\" -- a materially more useful record for whoever encounters the same large failure count next and would otherwise have to re-investigate it from scratch.'", "pain_score": 1, "importance": 6, "reflection": "", "confidence": 0.9, "source": {"skill": "learn", "profile": "manual", "run_id": "manual_8bf6b0"}, "evidence_ids": ["2026-08-02T14:51:33.276838+00:00"]} |
0 commit comments