fix(skills): pull upstream skill runtime resolution to stop event-loop starvation

The fork's listRuntimeSkillEntries rematerialized every skill's files from the DB on every heartbeat run dispatch — fs.rm + fs.mkdir + per-file readFile/writeFile, sequentially per skill. With 24 configured skills and 5 concurrent agents, this saturated the Node event loop badly enough that executeRun continuations couldn't reach activeRunExecutions.add() within the orphan-reaper's 5-min threshold, causing reaper to false-positive runs as "process_lost". Upstream's listRuntimeSkillEntries calls resolveRuntimeSkillSource, which checks if the materialized directory already exists on disk and short- circuits when it does. Fixes the symptom at the root. Replaces these files with upstream/master content: - server/src/services/company-skills.ts - server/src/services/heartbeat.ts - server/src/services/workspace-runtime.ts - server/src/services/company-portability.ts - server/src/routes/company-skills.ts - server/src/routes/agents.ts - packages/adapter-utils/src/server-utils.ts Pulls in supporting upstream files: - server/src/services/catalog-provenance.ts - server/src/services/skills-catalog.ts - server/src/services/github-fetch.ts - server/src/services/portable-path.ts - packages/skills-catalog/ (new package) - packages/db document_annotation_* schema + migration 0091 - packages/shared document-annotation types/validators Drops fork features (to be re-evaluated later): - Gitea/Forgejo git skill sources (server/src/services/git-source.ts deleted) - PAT support for private skill repos - Fork-specific secret-export portability extensions Adds agentId: null to acquireRunLease test-probe call in routes/agents.ts to satisfy the fork's environment-runtime agentId requirement (kept). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-29 09:26:51 -04:00
parent 562693197a
commit 548d958f18
52 changed files with 24613 additions and 2036 deletions
@@ -0,0 +1,93 @@
+---
+name: github-pr-workflow
+description: Prepare a GitHub pull request from a feature branch — branch hygiene, commit shape, title/body, verification notes, screenshots for UI work, and replies to review comments.
+key: paperclipai/bundled/software-development/github-pr-workflow
+recommendedForRoles:
+  - engineer
+tags:
+  - github
+  - pull-requests
+  - code-review
+  - release
+---
+
+# GitHub Pull Request Workflow
+
+Ship a PR a reviewer can land without follow-up clarifying questions. The aim is high signal in the title and body, evidence the change works, and clean replies when feedback comes in.
+
+## When to use
+
+- You are about to open a PR for a change that is functionally complete.
+- A reviewer left comments and you need to respond and push fixes.
+- A PR has been open more than a day and needs to be brought back into shape (stale conflicts, missing description, missing verification).
+
+## When not to use
+
+- The change is not yet functionally complete. Finish the work first; draft PRs that bounce on review are noise.
+- The repository uses a non-GitHub forge. Adjust to that forge's conventions; do not force GitHub-isms.
+
+## Branch hygiene before opening
+
+- Rebase or merge from the target base so the diff is current.
+- Squash WIP commits into reviewable units. Prefer one commit per logical change; do not force one-commit-per-PR if the work is genuinely multi-step.
+- Confirm tests, typecheck, and lint pass locally. Note any deliberate skips in the PR body.
+- Remove debug prints, commented-out code, and `TODO` markers that are not tracked.
+
+## PR title
+
+- Imperative mood, under 70 characters.
+- Lead with the user-visible change, not the file touched. `Allow CSV export from reports table` beats `Update reports.tsx`.
+- If the repo uses an issue prefix convention (`PAP-1234:`, `[security]`), follow it.
+- No trailing period.
+
+## PR body
+
+Use this structure:
+
+```md
+## Summary
+- 1–3 bullets describing what changed and why.
+
+## Implementation notes
+- Anything non-obvious in the diff: trade-offs, dropped alternatives, gotchas.
+- Migration or config implications.
+
+## Verification
+- The exact commands or steps you ran.
+- Screenshots or short clips for UI changes (required if pixels moved).
+- Edge cases you exercised by hand.
+
+## Risk and rollback
+- What breaks if this is reverted, and how to revert cleanly.
+```
+
+Skip the `Risk and rollback` section only for clearly trivial PRs (typos, docs).
+
+## Verification evidence
+
+- Tests passing in CI is necessary, not sufficient. Reviewers also need to know the change behaves correctly end to end.
+- For UI work, include screenshots of the golden path and one edge case. Tag dark and light mode if the project supports both.
+- For migrations, include a dry-run plan and reversal steps.
+- For performance changes, include a before/after measurement, not adjectives.
+
+## Replying to review comments
+
+- Reply on every comment, even with just "fixed in <commit-sha>" — silent fixes leave the reviewer guessing.
+- Push fixes as new commits while review is active; do not amend during review unless the reviewer agrees.
+- If you disagree with feedback, say so with one sentence of rationale and let the reviewer decide. Don't escalate over comments.
+- Re-request review explicitly after pushing changes.
+
+## Merge checklist
+
+- All required checks green.
+- All review comments resolved.
+- PR title/body still accurate (update if scope changed mid-review).
+- Linked issue moves to `in_review` or `done` per project convention.
+- Delete the branch after merge unless it is a long-lived integration branch.
+
+## Anti-patterns
+
+- PR description that says "see commits". Reviewers should not need to read the log.
+- Mixing refactor and behavior change in the same PR with no separation in the body.
+- "Address feedback" commits that bundle unrelated edits. One commit per round of feedback is fine; one commit for everything in flight is not.
+- Force-pushing during active review without telling the reviewer.