Skip to content

parley-deck-skill 2.1.0

Choose a tag to compare

@feci feci released this 01 Aug 00:00
· 20 commits to main since this release

parley-deck-skill 2.1.0

A sixth skill, and the payload-integrity mechanism that makes shipping it defensible.

parley-bidding

Evidence-backed bidding on software procurements: discovery, qualification, requirements
analysis, bid preparation, release freezing, portal staging and submission. Seven local,
deterministic Python tools; adapters for Cosinex/DTVP, NRW and subreport ELViS, plus a manual
profile capped at operator-attested proof.

Every consequential step is held by a human. Tender and portal content is treated as
untrusted evidence rather than as instruction. The skill never handles a password, cookie, token
or MFA code, and it never treats an upload as a submission or a green screen as a receipt.

It installs by default, including on install --force upgrades. What expands is availability,
not permission — use --no-addons, or --only without it, to leave it out.

Add-on payload integrity

An add-on may now ship a parley-addon.json manifest listing every file with its SHA-256 and an
aggregate digest. The install marker records what was verified at install time, so doctor can
tell a faithfully copied tree from a damaged one.

The defect this exists against: validateInstalledPayload asked an add-on directory a single
question — is SKILL.md there? — so a tree gutted to that one file reported valid.

This is defect detection, not tamper resistance. Anyone who can rewrite the payload can
rewrite the marker beside it. It catches partial copies, interrupted installs, stray generated
files and accidental edits.

Installation and removal are atomic across the whole fleet

Not merely per skill directory and not merely per target. The complete target × unit plan is
checked before the first write or deletion, and a predictable failure anywhere produces zero
writes and zero deletions.

Removal is a transaction rather than a prediction: every destination is renamed aside first —
a rename needs permission on the parent only — and only once the whole fleet is set aside is
anything deleted. A rename failure rolls back and deletes nothing.

--force overrides whose tree may be replaced or removed. It does not suppress the
feasibility checks, and it does not let recorded data widen the command's path scope.

Known limits, stated rather than discovered

  • Installer mutations are single-writer. Do not run two install/uninstall commands, or
    another skill manager targeting the same skills roots, at the same time. Concurrent processes
    are not isolated; an overlapping rollback can invalidate a command that already reported
    success. After any suspected overlap, serialize, run doctor, and reinstall.
  • Only parley-bidding ships a manifest. Installing all six skills with a third-party
    installer reports one valid-unmanaged and five malformed.
  • python3 is looked for by name. A Windows host where only python exists reports the
    add-on unavailable — the fail-safe direction.
  • The Python leg requires 3.10+ and refuses older interpreters rather than skipping.

Verified

368 node tests, 0 fail, under python3 3.14.6 and again under 3.9.6. Python leg 54/54 across seven
files on 3.14. Manifest check ok — 47 files, aggregate unchanged since first integration.

Reviewed over 24 rounds by three independent agents; the final round was a unanimous accept.