Define a fuller cross-repo hack-ink Python policy beyond python-policy

[aurexav]

Summary

python-style has been renamed to python-policy, and its current direction is correct: keep it focused on runtime boundaries, environment/tooling guidance, and deferring to each touched project's checked-in config and bootstrap path.

The remaining gap is separate from that rename. hack-ink still does not have a fuller cross-repo Python policy that tells contributors what the expected conventions are for:

• formatter authority
• linting expectations
• typing expectations
• testing expectations
• canonical local verification before claiming completion

Problem

The narrowed python-policy skill can tell agents not to invent tools or override project-configured quality gates, but it does not yet answer the higher-level question of what hack-ink wants Python work to look like across repos when those tools and gates do exist.

That leaves Python changes without the same level of explicit, repeatable guidance that exists elsewhere in the stack.

Desired outcome

Define a separate, explicit cross-repo Python policy artifact or companion guidance that complements python-policy instead of overloading it.

Acceptance criteria

• Keep python-policy scoped to runtime boundaries, packaging/tooling boundaries, and "follow the touched project's checked-in config" guidance.
• Define how formatter authority should be decided and documented for Python work across hack-ink repos.
• Define the expected linting posture for Python code and tooling.
• Define the expected typing posture for Python code, scripts, and helpers.
• Define the expected testing posture for Python changes, including lightweight tooling/script changes.
• Define the canonical verification convention contributors should run and report before completion.
• Clarify where this broader policy should live and how repo-local Python docs/skills should reference it.

Notes

This issue is not asking python-policy to invent repo-wide tools for projects that do not configure them. It is asking hack-ink to make its cross-repo Python quality conventions explicit so repo-local guidance can point to a stable standard.