Skip to main content

PactKit

PyPI version Python CI License: MIT

CODE is the Law. Data is the Truth. Prompt is ONLY instruction. AI is ONLY creativity.

PactKit (Pact 契约 + Kit) is a lightweight dev-enablement scaffold: it gives AI coding assistants the standards, specs and methods of a disciplined engineering workflow, without getting in the way. Ordinary questions and ordinary coding never activate the workflow — you opt in per task. There is no admin plane, no central control, and nothing that cannot be uninstalled.

Deterministic operations run as code, not prompts (CODE is the Law). Decisions are grounded in data, not memory (Data is the Truth). 55 CLI subcommands, 9 specialized agents, 12 commands, 25 skills, and a Plan-Act-Check-Done lifecycle you invoke when you want it. One pip install deploys to all 4 supported IDEs (adapters are opt-in extras).

Supported AI Tools

Tool Format Command
Claude Code Classic pactkit init
OpenCode OpenCode pactkit init
Codex CLI Codex pactkit init
GitHub Copilot Copilot pactkit init --format copilot

pactkit init deploys all 4 IDE formats at once. Use --format <name> to target a single IDE.

Gate coverage differs by host: Claude Code and Codex CLI get the full gate set through native hooks; OpenCode and Copilot fall back to the git-hook layer, which covers the commit and push gates but not the pre-tool ones (auth_gate, secrets_gate, tamper_guard, spec_guard).

What it looks like

You:  /project-sprint "Add OAuth2 login"

 Plan   System Architect scans codebase, writes Spec, updates Board
 Act    Senior Developer writes tests first (RED), then code (GREEN)
 Check  QA Engineer runs 6-phase audit (security + quality + spec alignment)
 Done   Repo Maintainer gates regression, archives story, commits

The P.A.C.T. Governance Contract

The name says it all — Pact means covenant. These four principles define the boundary between human intent and AI execution:

P   Prompt   is ONLY instruction   Tells AI how to act — defines process, never state
A   AI       is ONLY creativity    Formatting, summarization, language — never deterministic logic
C   Code     is the Law            Sole executor of deterministic operations — no bypass, no approximation
T   Truth    Data is the Truth     Factual basis for all judgment — no memory, no inference, no fabrication
  • If a script exists → use it. Never reimplement in natural language. (C)
  • If data is available → read it. Never guess or recall from memory. (T)
  • Prompts define HOW, never WHAT. Current state comes from data, not docs. (P)
  • AI formats, summarizes, and creates. AI does not parse, compute, or fabricate. (A)

Read the full philosophy: docs/architecture/governance/philosophy.md

Why PactKit?

  • P.A.C.T. Governance — A contract between humans and AI agents, with clear boundaries
  • Multi-Agent Ensemble — 9 specialized agents collaborate, each with constrained tools
  • Full PDCA Lifecycle — Plan -> Act -> Check -> Done, with quality gates at every stage
  • Safe by Design — TDD-first, safe regression, pre-existing test protection
  • Multi-Tool Support — Works with Claude Code, OpenCode, and Codex CLI
  • AI-Native SDLC, Operationalized — The artifact chain, gates, and audit trail that Anthropic's engineering practice describes — running across all 3 hosts

AI-Native SDLC Alignment

Anthropic's engineering team has published their practice for an AI-native software development lifecycle: six stages, each producing a committed artifact, humans at the gates, and the commit chain as the audit trail. PactKit operationalizes that model today — across all 3 supported hosts:

AI-Native SDLC Practice PactKit mechanism
Plan — intent.md Ideas become committed artifacts with provenance /project-clarify -> /project-plan (Spec + Story, timestamped in git history)
Design — spec.md Requirements + design in one pass; policies applied at generation time Spec generation reads rule modules; spec_guard keeps the Spec law during Act
Build — plan.md No code before an accepted plan; guardrails as code, not prompt discipline Spec lint + consistency check gate /project-act; enforcement gates enforce what prompts can only state
Test — diff + tests Sessions self-verify; steering config is regression-tested TDD loop + regression gates; commit-gate blocks RED suites with skip != pass transparency
Deploy — PR + findings Multi-pass review; hooks as allow/ask/block gates auth_gate authorization pairs, push_gate, tamper_guard — every block and bypass audited
Maintain Incidents feed the next cycle Gate telemetry + friction stats (pactkit stats) decide what to tune next

Beyond the published practice: the same governance runs on Claude Code, OpenCode, and Codex CLI; interrupted sessions leave machine-observable outcome_unknown fences that block resume until the gate re-runs; and every gate decision lands in .pactkit/enforcement/ as an audit record.

Installation

pip install pactkit

Requires Python 3.10+ and one of:

The base install is dependency-light (pyyaml only). Host adapters are opt-in extras — install the ones for the IDEs you use:

Optional Extras

pip install pactkit[opencode]    # OpenCode adapter
pip install pactkit[codex]       # Codex CLI adapter
pip install pactkit[lint]        # Includes ruff for lint gate
pip install pactkit[visualize]   # Includes tree-sitter for AST analysis
pip install pactkit[test]        # pytest + tomli (Python 3.10) for the test suite
pip install pactkit[all]         # Everything above

These tools enhance PactKit but cannot be distributed via pip. Run pactkit deps check to see what's missing and pactkit deps install for guided platform-aware installation:

Tool Purpose Install
gh GitHub CLI (issue sync, release, PR) brew install gh
codegraph Code symbol index & call chain analysis npm install -g codegraph

Quick Start

# Deploy to all 3 IDEs at once
pactkit init

# Update to latest playbooks (preserves your custom content in CLAUDE.md)
pactkit update
Single-IDE deployment
# Deploy to one IDE only
pactkit init --format classic    # Claude Code
pactkit init --format opencode   # OpenCode
pactkit init --format codex      # Codex CLI

Then in any project:

# Clarify — Surface ambiguities before planning
/project-clarify "Add user authentication"

# Plan — Analyze requirements, create Spec
/project-plan "Add user authentication"

# Act — Spec lint + consistency check + TDD implementation
/project-act STORY-001

# Check — Security scan + quality audit (P0-P3 severity)
/project-check

# Done — Regression gate + auto-PR + conventional commit
/project-done

Or run the full cycle in one command:

/project-sprint "Add user authentication"

PDCA+ Workflow

Phase Command Agent What Happens
Clarify /project-clarify System Architect Ambiguity detection -> Structured questions -> Clarified brief
Plan /project-plan System Architect Clarify gate -> Codebase scan -> Spec generation -> Board entry
Act /project-act Senior Developer Spec lint -> Consistency check -> TDD loop -> Regression check
Check /project-check QA + Security 8-item security checklist + quality audit + spec alignment
Done /project-done Repo Maintainer Regression gate -> Archive -> Conventional commit
Release /project-release Repo Maintainer Version bump -> Snapshot -> Git tag -> GitHub Release
PR /project-pr Repo Maintainer Push branch -> Create pull request via gh CLI
Sprint /project-sprint Team Lead One-command automated PDCA orchestration; empty args = Wave Mode (parallel backlog stories via spec-graph waves + conflict matrix)
Hotfix /project-hotfix Senior Developer Fast-track fix bypassing PDCA (with traceability)
Init /project-init System Architect Bootstrap project structure and governance
Design /project-design Product Designer PRD generation -> Story decomposition -> Board setup

When to Use What

The core loop is Plan → Act → Done. Other commands plug in as needed:

You have a task
  │
  ├─ Vague idea, multiple features? ──→ /project-design
  │
  ├─ Unclear requirement? ──→ /project-clarify → /project-plan
  │
  ├─ Clear feature or bug?
  │   │
  │   ├─ Small fix (1 file, obvious)? ──→ /project-hotfix
  │   │
  │   └─ Needs design? ──→ /project-plan → /project-act
  │       │
  │       ├─ Security-sensitive? ──→ /project-check (QA audit)
  │       │
  │       └─ /project-done
  │           │
  │           ├─ On feature branch? ──→ /project-pr
  │           └─ Ready to release? ──→ /project-release
  │
  └─ Fully automated? ──→ /project-sprint (runs all phases)

Solo developer? Start with /project-plan/project-act/project-done. Add /project-hotfix for small fixes and /project-check when security matters.

Embedded Skills (auto-invoked by commands)

Skill Embedded In Purpose
Trace Plan Phase 1, Act Phase 1 Deep code tracing and execution flow analysis
Release Release Phase 1 Version release: snapshot, archive, Git tag

Agent Skills (invoked via agent roles)

Skill Available To Purpose
Draw visual-architect, system-architect Generate Draw.io XML architecture diagrams
Status system-medic Project state overview
Doctor system-medic Diagnose project health
Review qa-engineer PR Code Review
Analyze senior-developer (Act inline) Cross-artifact consistency check: Spec <-> Board <-> Test Cases

Agent Ensemble

PactKit deploys 9 specialized agents, each with constrained tools and focused responsibilities:

Agent Role Core Capability
System Architect Architecture design Maintain Intent Graph, write Specs
Senior Developer Full-stack development TDD loop, call chain analysis, hotfix
QA Engineer Quality gates Deep check (P0-P3), PR review
Security Auditor Security audit OWASP scanning, threat modeling
Repo Maintainer Repository ops Cleanup, archiving, Git conventions, releases
System Medic System diagnostics Configuration drift repair
Visual Architect Architecture visualization Draw.io XML generation
Code Explorer Code tracing Call graph + sequence diagram
Product Designer Product design PRD, story decomposition, board init

Skills

PactKit deploys 25 skills. That total is the 12 PDCA commands (registered as skills, so /project-plan and pactkit-visualize deploy the same way) plus the 13 tool skills below, auto-invoked by commands:

13 tool skills (4 scripted + 9 prompt-only):

Skill Type Purpose
pactkit-visualize Scripted Code dependency graph (Mermaid .mmd): file-level, class-level, call-level
pactkit-board Scripted Sprint board operations: add story, update task, archive
pactkit-scaffold Scripted File scaffolding: create spec, test files, git branches, skills
pactkit-report Scripted Interactive HTML dashboard from Mermaid architecture graphs
pactkit-trace Prompt-only Deep code tracing and execution flow analysis
pactkit-draw Prompt-only Generate Draw.io XML architecture diagrams
pactkit-analyze Prompt-only Cross-artifact consistency check: Spec <-> Board <-> Test Cases
pactkit-audit Prompt-only H1-H7 AI readiness assessment and hotspot analysis
pactkit-status Prompt-only Cold-start project overview (sprint + git + health)
pactkit-doctor Prompt-only Configuration drift detection and health report
pactkit-garden Prompt-only Codebase quality patrol: dead code, stale docs, duplication
pactkit-review Prompt-only PR code review with SOLID/Security/Quality checklists
pactkit-release Prompt-only Version bump, architecture snapshot, git tag

CLI Subcommands

PactKit ships 55 deterministic CLI subcommands — operations that were previously delegated to AI prompts are now enforced in Python code (the "C" in P.A.C.T.):

Command Purpose
pactkit init Deploy toolkit to AI coding assistant
pactkit update Update playbooks (preserves config)
pactkit upgrade Upgrade with format selection
pactkit adopt Create a minimal versioned contract for the current project
pactkit reconcile Preview or apply safe project-schema migrations
pactkit project-preflight Check adoption and compatibility before governed work
pactkit version Show installed version
pactkit schema Print document schemas
pactkit doctor Diagnose project health (HLD drift, board, config, deployment content parity, adapter skew)
pactkit spec-lint Validate spec structure (E001-E010, W001-W011; incl. dependency surface checks)
pactkit spec-graph Story dependency DAG: topological execution waves + file-conflict matrix (--json for orchestrators, --write-graph for Mermaid)
pactkit spec-status Update spec Status field (Draft/In Progress/Done)
pactkit guard Check project init markers
pactkit generate-id [--type story|hotfix|bug] Generate a decentralized time-prefixed item ID
pactkit context Generate context.md from project state
pactkit clean Remove stack-specific temp artifacts
pactkit lint Stack-aware lint with auto-fix and blocking modes
pactkit regression Classify changes (SKIP/FULL/IMPACT)
pactkit test-map Map source files to test files
pactkit coverage-gate Enforce 3-tier coverage thresholds (80/50/block)
pactkit visualize Conditional graph regeneration (lazy mode)
pactkit query Query call graph via codegraph: --callers, --callees, --chain [--down] (requires graph_provider: codegraph)
pactkit lesson-append Append lesson with specificity check and dedup
pactkit invariants-refresh Update test count invariant in rules.md
pactkit sec-scope Detect security scope for changed files
pactkit backfill-release Replace Release: TBD in completed specs
pactkit issue-sync GitHub issue lifecycle for BUG/HOTFIX items
pactkit lint-context Validate context.md structure
pactkit lint-lessons Validate lessons.md structure
pactkit lint-testcase Validate test case structure
pactkit done-verify Archive honesty gate: requirement→test evidence chain, checkbox↔case consistency, status machine (blocks /project-done on FAIL)
pactkit commit-gate Pre-commit test gate with skip≠pass transparency; stack-aware (pytest/npm test/go test/mvn/gradle); counts via junitxml — immune to repo addopts verbosity tricks — with exit-code-truthful failure messages; PreToolUse hook + git pre-commit/pre-push channels, auto-installed per format
pactkit gate Session context hooks (--hook session-start/pre-compact) + external-effect authorization (pactkit gate <scope> [--ttl-minutes N])
pactkit deps External dependency check (deps check) and guided install (deps install) for node/codegraph/gh
pactkit schema config List every pactkit.yaml key with default, effective value, and source
pactkit sync Sync codegraph index

Commit Path Convergence (2.26.0)

  • Single test executor: worktree and core.hooksPath layouts resolve the real git hooks path — the host PreToolUse pass defers to the shared git pre-commit hook instead of double-running the suite.
  • Real incremental selection: a changed test file maps to itself (test_X.py runs test_X.py); an empty mapping runs the fast layer with an explicit full-suite recommendation instead of silently escalating; polyglot repos run every detected workspace's native test command.
  • Observability: the gate prints its plan (strategy, reason, command, scope) before any test runs, streams pytest output, and records per-phase timings into the enforcement record.
  • Staged-first scope: the gate checks what this commit will introduce (git diff --cached); unstaged work is reported as excluded.

Verification Facts & Governance (2.26.0)

  • Verification records are keyed by content fingerprint (cross-story reuse); with no fresh, unambiguous preflight receipt the post-commit stamp lands unattributed instead of guessing a story.
  • PreCompact writes a lightweight marker — one context generation per compaction cycle.
  • The spec guard binds a receipt only while its spec hash matches and the receipt is fresh (expired/drifted receipts unlock with a reason).
  • telemetry.enabled: false skips event-stream writes without touching gate semantics.

Engineering Guidance by Gap (2.26.0)

  • The reuse classification (availability / applicability / decisions / evidence) lives once in the shared lifecycle capsule loaded by all four phases; Act loads guidance by gap — an empty pactkit risk result is never "no risk", 0 guides is valid when there is no gap, and confirmed risks past the first three are still read and verified.
  • pactkit risk --json returns the full per-concern decisions for review.

Enforcement Gates (2.25.0)

The hook layer enforces the rules prompt text can only state — protected branches, specs, credentials, and external effects survive a conflicting instruction instead of losing to it:

Gate Blocks Bypass (human/config only)
push_gate Direct push to a protected branch (default main/master) PACTKIT_ALLOW_DIRECT_PUSH=1 or enforcement.allow_direct_push
commit_gate Commits on protected branches (default) and RED test suites same as push_gate; develop keeps the full-suite rule
spec_guard Editing a spec that has an active preflight receipt (Spec is Law during Act) PACTKIT_ALLOW_SPEC_EDIT=1 or pactkit gate spec_edit
auth_gate External-effect commands (PR/release/publish/repo) until the user confirms pactkit gate <scope> TTL token or PACTKIT_AUTHORIZED=1
secrets_gate Literal credential material in commands (env-var indirection is exempt) PACTKIT_ALLOW_SECRET=1
tamper_guard Modifying enforcement artifacts (hooks, gate registrations, audit records) PACTKIT_ALLOW_CONFIG_EDIT=1

All blocks/bypasses are audited (.pactkit/enforcement/) and feed pactkit stats as gate telemetry (per-gate block counts, per-command invocation counts, authorization pairs) — the friction data that decides what to tune next.

Deployment Architecture

PactKit supports four deployment formats:

Claude Code (Classic)

~/.claude/
├── CLAUDE.md                 <- Project context entry point
├── rules/                    <- 21 rule modules (loaded per-command, not globally)
├── skills/                   <- 25 skill packages (12 commands + 13 tool skills)
└── agents/                   <- 9 agent definitions

Commands are deployed as skills (skills/project-*/SKILL.md), invoked with /project-plan.

OpenCode

~/.config/opencode/
├── AGENTS.md                 <- On-demand @reference index (lazy rule loading)
├── rules/                    <- 21 rule modules
├── commands/                 <- 12 command playbooks (auto-discovered, invoked via /)
├── agents/                   <- 9 agent definitions (mode: subagent)
├── skills/                   <- 13 tool skills (AI agent loads on demand)
└── opencode.json             <- Global config (model routing, instructions)

OpenCode uses dual mechanism: commands/ for user-facing PDCA entry points, skills/ for AI-invoked tools.

Codex CLI

~/.codex/
├── AGENTS.md                 <- Global constitution
├── config.toml               <- Model, sandbox, MCP config
├── rules/                    <- 21 rule modules
├── skills/                   <- 25 skill packages (12 commands + 13 tool skills)
└── .pactkit-version          <- Version marker for updates

Commands are deployed as skills (skills/project-*/SKILL.md), invoked with $project-plan.

Multi-Developer Collaboration

PactKit supports multi-developer workflows with Story ID prefixing:

# In pactkit.yaml
developer: alice

Story IDs become STORY-alice-001, preventing merge conflicts when multiple developers work on separate branches.

Project Structure (PDCA-managed)

PactKit's PDCA lifecycle manages a docs/ directory:

docs/
├── product/
│   ├── stories/                 <- One workflow/task fact file per Story
│   └── sprint_board.md          <- Optional generated read-only projection
├── specs/                       <- The Law — requirement specifications
├── test_cases/                  <- Gherkin acceptance scenarios
└── architecture/
    ├── graphs/                  <- Architecture graph files (Mermaid .mmd)
    ├── governance/
    │   ├── rules.md             <- Architecture decisions and invariants
    │   └── lessons/             <- One immutable record per lesson
    └── snapshots/               <- Versioned architecture graph snapshots

Session context is generated locally at .pactkit/context.md and is ignored by Git.

pactkit.yaml Configuration Reference

Field Type Default Description
stack string auto-detected Project stack (python, node, go, java)
developer string "" Developer prefix for Story IDs (multi-developer collaboration)
agents list all 9 Agent definitions to deploy
commands list all 12 Command playbooks to deploy
skills list all 25 Skills to deploy (12 commands + 13 tool skills)
rules list all 21 Constitution rule modules to deploy
enforcement object see below Gate configuration — protected_branches (["main","master"]), allow_direct_push (false), tamper_guard (true), spec_guard (true), auth_gate (true), secrets_gate (true), auth_ttl_minutes (30)
telemetry object enabled: true Local-only usage telemetry (.pactkit/events/). Set enabled: false to stop recording; gate verdicts are unaffected
exclude object {} Components to exclude (e.g., exclude.agents: [agent-name])
visualize.graph_provider string (absent) Graph query backend. Set codegraph to use .codegraph/codegraph.db for pactkit query. Absent = grep .mmd
ci object provider: none CI/CD pipeline generation (github, gitlab, none). Sub-fields: runner (default: ubuntu-latest), language_version (default: auto per stack), github_host (GHE server address), actions_ref (GHE actions prefix)
issue_tracker object provider: none External issue tracker (github, none)
hooks object disabled Opt-in hook templates (pre-commit, post-test, pre-push)
lint_blocking bool false Whether lint failures block commits
auto_fix bool false Whether to auto-fix lint errors
agent_models object {} Per-agent model overrides (haiku, sonnet, opus, inherit)
command_models object defaults Per-command model overrides for OpenCode deployment
write_scope object (absent) Declare source_roots/test_roots/docs_roots for non-standard directory layouts (e.g. frontend/src, backend/, directus-extensions/). It informs optional workflow integrations and project tooling; normal project-act work remains in the current session and is never blocked by a stale workflow scope.

Safe Regression

PactKit's safe regression system prevents agents from blindly modifying pre-existing tests:

  • TDD Loop — Only iterates on tests created in the current story
  • Regression Check — Read-only gate; pre-existing test failure = STOP and report
  • Done Gate — Full regression by default; incremental only when ALL safety conditions are met

Hierarchy of Truth (the "T" in P.A.C.T.)

Tier 1: Specs & Test Cases           <- The Law (CODE is the Law)
Tier 2: Tests                        <- The Verification (DATA is the Truth)
Tier 3: Implementation               <- The Mutable Reality

When conflicts arise: Spec wins. Always. The agent modifies code, never the spec.

MCP Integration

As of 2.26.0, PactKit is a lightweight development-enablement scaffold with zero MCP server injectionpactkit init no longer registers any server, and the self-hosted governance MCP server is retired (pactkit mcp prints the retirement note and migration path). Host-side MCP servers you configure yourself (Context7, Playwright, Chrome DevTools, Memory, …) still work: the playbooks reference them conditionally and skip gracefully when unavailable.

MCP Server Purpose PDCA Phase
Context7 Library documentation lookup Act
Playwright Browser automation testing Check
Chrome DevTools Performance/console/network Check
Memory Cross-session knowledge graph Plan/Act/Done

All MCP instructions are conditional — gracefully skipped when unavailable.

Upgrading

pip install --upgrade pactkit
pactkit update    # Updates all deployed IDEs

Use pactkit update --format <name> to update a single IDE.

Rolling back is pip install pactkit==<previous-version> followed by pactkit update. pactkit doctor reports a deployment whose files no longer match the installed CLI, which is how a partial rollback shows up.

Restricted and CI Environments

pactkit init and pactkit update accept flags for environments that cannot reach the network or answer prompts:

Flag Effect
--no-git Skips every git operation (hook installation, .gitignore edits) — for air-gapped or git-less setups
--no-external Skips external network calls (MCP registration, gh CLI, pip)
--non-interactive Auto-accepts defaults — for CI/CD

PactKit never sends your code or usage data anywhere. Telemetry is written locally under .pactkit/events/ and can be turned off with telemetry.enabled: false. The only network access is the package index you install from.

Troubleshooting

Start with pactkit doctor — it reports configuration drift, deployment parity against the installed CLI, adapter version skew, hook registration, and rule health. pactkit doctor --json emits the same data for scripts.

Symptom Likely cause What to do
A commit is blocked with commit-gate Tests are RED, or you are committing directly to a protected branch Fix the tests, or push a feature branch and open a PR. enforcement.allow_direct_push: true is for single-maintainer repos that work directly on main
A command is blocked with push-gate / auth-gate Direct push to a protected branch, or an external-effect command (gh pr create, npm publish, …) without authorization Run pactkit gate authorize <scope> after the user agrees, or have the user run it themselves
Gates behave inconsistently across teammates Deployments are stale — each clone updates independently pactkit update in that project, then pactkit doctor
pactkit doctor reports adapter skew pactkit-codex/-opencode version does not match core Upgrade the adapter extras; core and adapters are version-pinned to each other
The gate blocks work and you believe it is wrong Genuine gate bug PACTKIT_ALLOW_* env vars (see the gate table above) are the human channel; report the false positive with pactkit stats output

Contributing

See CONTRIBUTING.md for guidelines.

License

MIT

Release files for pactkit 2.27.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for pactkit 2.27.0
File Size Uploaded
pactkit-2.27.0.tar.gz 2.4 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for pactkit 2.27.0
File Interpreter ABI Platform
pactkit-2.27.0-py3-none-any.whl Python 3 none any Details

Total release size: 3.0 MB

Release files / pactkit-2.27.0.tar.gz

Download URL pactkit-2.27.0.tar.gz
Size 2.4 MB
Tags Source
SHA-256 checksum
How to use checksums
d4144a974f71f3a6bc32d7bac9b728b8139d9f7f0df05320b89b9faf1e320dba
BLAKE2b-256 checksum
How to use checksums
6fe978859f15a5553dd4ad2a22b02ce0447bff3503c2c62c334505e23d240bca
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.

Transparency log

Release files / pactkit-2.27.0-py3-none-any.whl

Download URL pactkit-2.27.0-py3-none-any.whl
Size 573.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
ee37d7a6b8de94fad4cae2b87f1ccab2a4b2fa8e81d7609d16393f5803362ac8
BLAKE2b-256 checksum
How to use checksums
eea9732a78db56c23c64f007986908c3809472dae94d01f0ef5fcbc3a75d711a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.

Transparency log

Release history Release notifications | RSS feed

3.0.1

2 release files

3.0.0

2 release files

This release

2.27.0 This release

2 release files

2.26.1

2 release files

2.26.0

2 release files

2.25.0

2 release files

2.24.2

2 release files

2.24.1

2 release files

2.24.0

2 release files

2.23.0

2 release files

2.20.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page