Skip to content

Prepare Python 1.3 documentation and independent runtime coverage validation #38

Open

Description

@abruption

Problem

The canonical Python skill currently describes baseline runtime 0.9.1 and published CLI coverage 1.0.1. Python 1.3.0 candidates add ordinary delivery explanations and route presets. These need explicit feature gates and consistent guidance without implying publication, permission, recipient identity, or ACK support.

Reviewed candidates

  • Runtime PR #325, source 6e1664ceca444f1f591cdb84780320e8f24e5ac9: text-only send --dry-run --explain.
  • Runtime PR #328, source 6510c93aa39e613adf2eeb4a35b0e9c0a1ebca7e: private route-only presets for macOS/Linux local/SSH Claude/Codex.
  • Runtime #296: determine documentation only after candidate implementation and contract review of the single-request metadata status slice; watch and new ACK support are excluded.

The first two sources are separately reviewed candidates, not an integrated runtime validation. Combined --preset / --explain examples require integrated-source evidence. As of 2026-10-22 the verified public Python runtime is 1.2.1.

Scope and acceptance

  • Update canonical Python SKILL and existing English/Korean/Japanese/Simplified Chinese usage guides; keep README changes brief and link to detailed guidance.
  • Preserve minimum 0.9.1 with feature-specific version/help checks. Full 1.3.0 is conditional on final feature scope and actual runtime publication. Preserve separate security guidance and experimental handoff exclusions.
  • Explain preview limits, explicit target/current preset revision, route-only storage, CAS, discovery versus stored configuration, and refusal without permission/ACL/mount workarounds. Never infer consumption/ACK or resend permission.
  • Decouple full-coverage validation from the receiver codexBin minimum of 1.0.1. Test a full 1.3.0/codexBin 1.0.1 positive case, independent mismatch negatives, numeric minimum <= full, and existing baseline/localized consistency.
  • Preserve TypeScript profiles, metadata, pins and runtime behavior. Decide the next Python skill version separately; do not reuse this local candidate as a new artifact of the existing published version.

Rollout and authorization

Finalize runtime source and feature floors, review canonical documentation, verify actual runtime publication, then seek separate skill merge/tag/release approval. Synchronize the Python compatibility snapshot separately using the published skill tag, peeled commit and exact SKILL SHA-256.

Current user authorization: create this issue and edit files on an isolated local branch. Do not create a PR, push, merge, tag, release, install or change operations. Current metadata and release pins remain unchanged during preparation. No milestone is selected: the existing v0.2.0/v0.3.0 milestones describe prior work and do not establish this release version.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions