provider-session-learning-transfer

name	provider-session-learning-transfer
description	Refresh provider session audit, identify post-audit/unassessed sessions, extract actionable learnings, and transfer them into repo notes and GitHub issues before a follow-up implementation session.
version	1.0.0
tags	["providers","sessions","audit","learnings","github","handoff","transfer"]

Provider Session Learning Transfer

Use when the user asks to assess recent AI-provider sessions and push the learnings into repo artifacts, issue trackers, or handoff notes.

When to use

• "Assess recent/unassessed sessions"
• "Transfer learnings to the repo ecosystem"
• "Update issue notes before a dedicated Claude/Codex/Gemini session"
• "Review provider activity since the last audit/report"

Core idea

Do not just read the existing provider audit and summarize it. First refresh the audit, then identify what happened after the prior audit timestamp, then transfer only the actionable findings into the target repo artifacts.

Workflow

0. Prefer the tracked delta section when available

If the refreshed audit already includes a recent_activity_since_previous_audit executive-summary section, use it as the first-pass filter for which providers actually need deeper inspection.

Treat this as the canonical answer to:

• which providers had post-audit work
• how many post-hook records they produced
• how many runtime sessions they opened
• which recent Bash families / missing repo reads matter first

This avoids re-deriving the same cutoff analysis ad hoc each time.

1. Load existing provider audit artifacts

Read:

• analysis/provider-session-ecosystem-audit.json
• docs/reports/provider-session-ecosystem-audit.md

Capture the prior generated_at timestamp. This is the boundary for "unassessed" work.

2. Inventory provider log coverage

Check for session_*.jsonl under:

• logs/orchestrator/claude/
• logs/orchestrator/codex/
• logs/orchestrator/hermes/
• logs/orchestrator/gemini/

Do not assume every provider has recent work just because logs exist historically.

3. Refresh the audit before drawing conclusions

Run:

• bash scripts/cron/provider-session-ecosystem-audit.sh

Then reread the JSON/Markdown outputs and note the new timestamp plus changed metrics.

4. Identify truly unassessed work

Use the prior audit timestamp as cutoff and count records/sessions after that point for each provider.

Recommended output:

• provider
• records_after_prior_audit
• sessions_after_prior_audit

Important: this is the best quick test for whether Codex/Gemini/Claude/Hermes actually contributed anything new since the last audit.

Implementation note:

• Prefer the audit JSON if it actually exposes top-level delta blocks such as recent_activity_since_previous_audit.
• But do not assume those keys exist on every refresh. In live use, the refreshed JSON sometimes only contains generated_at, repo_root, logs_root, providers, and executive_summary, while the Markdown report still renders the recent-activity and corpus-change sections.
• Therefore, probe the JSON shape first. If those top-level delta blocks are absent, treat docs/reports/provider-session-ecosystem-audit.md as the authoritative recent-activity source and extract provider deltas from the Markdown headings/sections instead of concluding the data is unavailable.
• The per-provider objects under providers.<provider> may also omit the same delta structure even when the Markdown renders it, so keep Markdown and raw logs as the fallback truth for deeper drill-down.

5. Inspect only relevant recent sessions

Filter recent post-audit logs for the user’s target domain (for example tax, filing, issue planning, docs, etc.).

For domain filtering, inspect fields such as:

• tool
• repo
• cmd
• file
• search_query
• skill_name

Do not overfit to all provider activity. Extract the pattern that is actually reusable for the next session.

6. Derive the transferable learning

Prefer operational learnings, such as:

• packet-first workflow before live browser/tool session
• material blockers vs low-impact uncertainties
• explicit pre-submit checkpoints
• dedicated handoff prompt instead of restarting from memory
• binary go/no-go decision early in the next session

For provider-audit work specifically, separate two different stories:

1. true recent event-time activity since the prior audit
2. snapshot/corpus growth beyond recent activity (often export backfill or improved classification)

If a provider has little or zero recent event-time work but still shows large corpus growth or missing-read deltas, transfer that as a classification/export interpretation, not as a claim that the provider recently "did" that work.

Avoid dumping raw metrics into business notes unless the metrics themselves matter.

7. Transfer learnings into the repo ecosystem

Update both:

1. durable repo notes/docs in the target repos
2. the active GitHub issue(s) or tracker items that the next session will use

Good transfer targets:

• tax/session summary note
• strategy/decision note
• issue comment on the active filing/execution issue
• handoff prompt source file

Before creating new follow-up issues, search existing open and closed issues for the audit's primary issue keys and provider names. Prefer commenting/updating an existing open issue over duplicating it. For closed issues, reopen only when fresh recent broken-path evidence exists; if the refreshed audit shows zero recent missing reads or improving drift, leave the issue closed and add a monitoring/transfer comment instead. Create a new issue only when no exact open operational anchor exists.

8. Pre-close adversarial review gate

Before committing, pushing, posting final closeout comments, or treating the transfer as complete, run the applicable adversarial review gate from docs/standards/AI_REVIEW_ROUTING_POLICY.md and software-development/multi-provider-adversarial-review.

Minimums:

• Use three-agent review by default for meaningful transfer, governance, standards, skill, hook, harness, file-structure, or test-suite work.
• Use a scaled sanity-check prompt only for low-risk transfer reports, audit refreshes, or narrative documentation with semantic repo impact; do not skip the gate.
• Record reviewer verdicts and the durable evidence path or issue/PR comment URL before the transfer can be marked complete.
• The authoring agent/provider does not count as an independent reviewer.

9. Verify the transfer

Before finishing, verify:

• refreshed audit files are updated
• target repo files are modified in the intended locations
• GitHub comment/edit succeeded
• transferred learnings are framed as next-session execution guidance, not just retrospective commentary
• Step 8 review evidence is recorded in the transfer report with provider verdicts, committed artifact path(s), issue/PR comment URL(s) when they exist, evaluated commit SHA or exact revision identifier, and any reviewer waiver/unavailability noted
• exact transfer artifact paths are clean after commit/push, even if unrelated session-generated repo dirt remains elsewhere

If the session is resumed after context compaction, re-run a scoped closeout pass rather than relying on the pre-compaction narrative: compare local HEAD to origin/main, check git status --short -- <artifact paths>, validate JSON/report/skill files as applicable, then record unrelated dirty paths separately. This is mandatory when the compaction note says summary generation was unavailable. See references/2026-05-08-plan-review-closeout-and-compaction-resume.md for the #2657 pattern.

After completing a provider-session transfer or plan-review closeout, perform the session-end skill-library review while the learning is fresh. Prefer patching this class-level skill or adding a references/ note over creating narrow one-session skills; include concrete closeout pitfalls such as compaction recovery, remote verification anomalies, unrelated dirty-state preservation, and tool-budget interruptions.

If a session hits a hard tool-call limit before implementation/closeout, write the final response as a resumption handoff rather than implying completion. Preserve live issue state, plan path, inspected files, unrelated dirty paths, and explicit "not completed" statements. On resume, re-run live checks and continue from the first unmet acceptance criterion; see references/2026-05-08-tool-budget-interruption-handoff.md.

9a. Exit handoff for provider-transfer sessions

See references/2026-05-08-exit-closeout-pattern.md for a concrete closeout example including the remote ref-lock push anomaly.

When the user says "document and prepare to exit" after provider-session transfer work, produce a concise durable handoff before final response:

1. Write docs/handoffs/session-YYYY-MM-DD-provider-session-learning-transfer-exit.md with scope completed, durable artifact paths, pushed commits, known dirty-state exceptions or preservation rationale, issue handles, and explicit note if no external send/action occurred.
2. Inspect git status --short --branch, git rev-parse HEAD, and git rev-parse origin/main before writing the final handoff so the report reflects live state, not pre-compaction memory.
3. Preserve and commit intentional session artifacts discovered during exit prep instead of silently discarding them; if a dirty/untracked artifact is unrelated or evidence-preserving, name it in the handoff and final response.
4. Run git diff --check, commit the handoff plus intentional artifacts, push, then verify HEAD == origin/main, ahead/behind is 0/0, and the working tree is clean before declaring exit-ready.
5. If git push emits a remote ref-lock rejection but a fetch/remote check shows origin/main already equals local HEAD, record the verified landed state and do not churn with redundant retries.

10. Convert the top actionable transfer into the next planning gate when asked

If the user asks for the next logical step after a provider-learning transfer, do not automatically rerun the audit. Prefer converting the highest-priority concrete remediation issue into the next gate:

1. Pick the most actionable child issue, not the broad parent, using the refreshed report and issue state. Example: a concrete stale-reference cleanup child beats the parent migration-debt backlog.
2. Read the canonical plan and latest transfer bundle.
3. Reconcile the transfer into the plan only if it changes evidence, scope framing, or approval readiness. Avoid broadening the implementation branch when the transfer is only standing-risk/negative evidence.
4. Update the local plan status and planning index to plan-review.
5. Post a GitHub approval-gate comment via --body-file, add status:plan-review, and remove stale conflicting status labels.
6. Commit/push the exact plan-status changes, then verify both live GitHub labels/comments and remote origin/main.

Provider-review unavailability details and the #2657 Codex/Gemini handling pattern are captured in references/2026-05-08-plan-review-provider-unavailability.md. Use that reference when review fanout partially fails during a provider-learning transfer.

Pitfall: workspace-hub often has concurrent writers and background git/status processes. If .git/index.lock appears, inspect live git processes first, remove only stale locks, and re-run git status. If git push reports a remote ref-lock rejection but git ls-remote origin refs/heads/main already equals local HEAD, treat the push as effectively landed after verification instead of retrying blindly.

Heuristics that worked well

If you rerun bash scripts/cron/provider-session-ecosystem-audit.sh after drafting or posting transfer notes, immediately re-read analysis/provider-session-ecosystem-audit.json / docs/reports/provider-session-ecosystem-audit.md and patch the transfer report plus posted issue comments to the final generated_at value. Timestamp drift between the audit, durable report, and issue comments makes future "unassessed since boundary" work ambiguous.

When committing/pushing the transfer, verify remote state after any odd push error. A push can report a remote ref-lock rejection like cannot lock ref ... is at <new> but expected <old> even when the remote has advanced to the just-created commit. Before retrying or rebasing, run git rev-parse HEAD and git ls-remote origin refs/heads/main; if both match, treat the push as successful and avoid unnecessary conflict recovery.

Heuristics that worked well

• If recent Codex/Gemini counts are zero after the prior audit, say so explicitly and focus on the providers with real post-audit work.
• The most useful learnings may come from one provider’s recent workflow even when the task asked for “all providers”.
• For filing work, the reusable pattern is usually about session structure and evidence gating, not tax law interpretation.

Recommended transfer format for tax/session work

Add a short section like:

• Cross-provider learnings transfer —

Include:

1. packet-first filing workflow
2. material blockers list
3. explicit reconciliation/pre-submit checkpoints
4. dedicated handoff prompt requirement
5. first-decision binary: finish now vs extension/triage

Pitfalls

• Do not rely on stale audit outputs without rerunning the audit.
• Do not assume “recent provider activity” means all providers contributed recently.
• Do not bury the actual next-session guidance inside audit statistics.
• Do not update only docs and forget the active GitHub issue the operator will actually open next.