Summary

When a managed project uses a non-GitHub tracker (e.g. Jira, Linear), the framework hooks that validate ticket references — validate-pr-create.sh, verify-commit-refs.sh, require-skill-for-issue-create.sh — still attempt to resolve ticket IDs against GitHub Issues and block on 404.

Steps to reproduce

1. Register a managed project in apexyard.projects.yaml with a Jira/Linear tracker.
2. Set tracker.kind in the ops fork's .claude/project-config.json to e.g. "jira" or "none".
3. cd workspace/<project>/ and attempt to open a PR with gh pr create.
4. The validate-pr-create.sh hook fires, resolves REPO_ROOT via git rev-parse --show-toplevel — which returns the managed project's git root, not the ops fork root.
5. The hook cannot find .claude/project-config.json (it's in the ops fork, not the project clone), falls back to tracker.kind = "gh", and calls gh issue view <N> for the Jira/Linear ticket ID.
6. The call fails with 404 / "could not resolve to an Issue" and the hook blocks.

Expected behaviour

When working inside workspace/<project>/, the hooks should walk up to find the ops fork root (same path resolution that _lib-ops-root.sh uses) and read the tracker config from there, so tracker.kind and id_pattern are correctly applied.

Actual behaviour

Hooks fall back to tracker.kind = "gh" because they resolve config relative to the managed project's git root, not the ops fork root. Any non-GitHub ticket ID (e.g. PROJ-123, ENG-45) is treated as a missing GitHub issue and the command is blocked.

Workaround

Setting tracker.kind = "none" in the ops fork's .claude/project-config.json unblocks the hooks but disables ticket existence verification entirely, which is a broader trade-off than necessary.

Environment

• Framework: me2resh/apexyard (current dev)
• Trigger hooks: validate-pr-create.sh, verify-commit-refs.sh, require-skill-for-issue-create.sh
• Tracker in use: non-GitHub (external)

Suggested fix

In each affected hook, replace the current git rev-parse --show-toplevel-based config resolution with the _lib-ops-root.sh walk-up so the ops fork's project-config.json is found regardless of which directory the operator is working in.