Capability assessment
Doc type: Explanation · Applies to: POSE 1.4.x
Assessment date: 2026-08-17
Scope: POSE open-source distribution
Evidence baseline: published v1.4.3 release artifacts, four
consecutive real cut/published/independently-verified releases (v1.4.0
through v1.4.3), independent release verification and mainline test suite
Purpose: measure fitness against POSE's own promises and relevant
best-of-breed practices, not manufacture a universal product ranking.
Structured source of truth: the scores, evidence references and gaps in this document are maintained as a POSE-native artifact at
.pose/capabilities/assessment.md, validated bypose assess(see the CLI reference). This prose remains the narrative; the artifact is the data.
Method
Score each mechanism against its stated purpose:
| Score | Interpretation |
|---|---|
| 0 | Absent |
| 1 | Designed or scaffolded |
| 2 | Functional in a narrow path |
| 3 | Reliable for a single repository or early team adoption |
| 4 | Strong product capability with clear operational contracts |
| 5 | Reference-grade capability with ecosystem, scale and independently verified evidence |
The target is not always 5. A local engine should not become a hosted portal only to improve a score. Compare each mechanism with the strongest relevant practice while preserving POSE's boundary.
Executive result
Since the previous narrative sync (2026-08-14, against the v1.2.0 release
contract), the repository shipped four consecutive real releases — v1.4.0
through v1.4.3 — three of them (v1.4.1-v1.4.3) same-day follow-up fixes for
defects an upgrade-path field audit found on seven real, independently-owned
external repositories, not synthetic fixtures. The repository now carries 10
completed roadmaps and 115 completed specs, including the component-aware
and convergent-review increments delivered in v1.1.0/v1.2.0 and the four
audit-driven fixes delivered this cycle: pose-upgrade-path-audit-fixes,
pose-derived-index-self-referential-leak,
pose-update-instance-directory-completeness and
pose-discovery-gitignore-and-root-alias-fix. Every item in the prior
assessment's P0 and P1 improvement plan is delivered; most of P2 is
delivered as well, with one item (durable multi-team orchestration, visual
operation, tenant-scoped policy distribution) still correctly out of scope
for a local-first engine and living in Harne8 by design.
POSE has moved from "credible open-source, single-repo governance engine
with a large distance to reference-grade" to a governance engine that is
reference-grade across most of its own claimed surface, now proven not only
in CI but against real, independently-owned installations. v1.0.0 added
automatic, privacy-bounded CLI/MCP usage analytics and completed the
production-scoped five-metric DORA contract; the immutable release lifecycle
was also exercised through tagged, published and independently verified
states, repeated on four consecutive real releases this cycle. The
v1.1.0/v1.2.0 releases add deterministic component-aware review plans,
sealed semantic review bundles whose separate attestations no longer
invalidate the subject they approve, and automated evidence attestation
(pose review auto-attest). Distribution trust, structured validation, MCP
protocol completeness, extension lifecycle and cross-repository portfolio
projection are no longer design-only claims. The v1.4.x cycle closed the
remaining gap between "tested in the abstract" and "proven against real
upgrade paths": an 11-defect field audit of pose update/pose install
against real installations fixed locale-handling reliability, doctor
blind spots, a second class of locale defect beyond the original parity
bug, discovery false positives (gitignored trees, duplicated root
aliases), and a self-referential leak of pose-dist's own computed graph
data into fresh instances.
The remaining distance is concentrated in production-grade identity/secret management for shared MCP deployments, a populated third-party extension ecosystem, upstream WinGet publication/a Homebrew tap, and human adjudication of observed usage findings. These are stated boundaries or owned follow-ups, not capabilities silently presented as complete.
| Mechanism | Current | Target | Summary |
|---|---|---|---|
| Install, upgrade and local-first runtime | 5 | 5 | Verified multi-platform download and proven in-place upgrade; package-manager channel limits are explicit |
| Spec lifecycle and closeout | 5 | 5 | Requirement-to-check-to-commit trace and structured amendment history close the prior gap |
| Task routing, workflows, rules and skills | 5 | 5 | Agent Skills contract is now a CI gate across all 11 skills, both locales |
| Dependencies, readiness and roadmaps | 4 | 5 | Cross-repository portfolio projection with ownership/criticality; no capacity/time scheduling by design |
| Validation matrix and structural checks | 5 | 5 | Python/.NET/monorepo stacks, JSON/JUnit/SARIF, timeouts and Harness isolation all delivered |
| Evidence, history and insights | 4 | 5 | Requirement trace links checks to commits; release artifacts are signed, per-report evidence is not |
| Follow-ups and recurrence | 5 | 5 | Owner/SLA and measured intervention effectiveness close the prior gap |
| Knowledge governance | 4 | 5 | Usage traceability and explainable semantic-advisory retrieval delivered; RBAC mapping still open |
| MCP and agent interoperability | 5 | 5 | Golden-fixture catalog conformance, active connection context, uniform project scoping, pagination, 50 tools |
| Policy, identity and audit | 4 | 5 | Identity-gated validation orchestration and bounded audit fields; SPIFFE/secret-mgmt/TLS still external |
| CI, release and supply-chain trust | 5 | 5 | Signed, SBOM'd, provenance-attested releases; CodeQL/govulncheck/gitleaks/Scorecard all green |
| Import and adoption interoperability | 4 | 5 | Three executable, end-to-end-tested brownfield kits; no plugin-based custom source schemas yet |
| Metrics and observability | 5 | 5 | Automatic local usage, five scoped DORA metrics and OTel server signals; human finding adjudication is open |
| Documentation, localization and diagnostics | 5 | 5 | Locale-parity bug fixed, self-inspecting docs tests, guided remediation, docs-as-tests monorepo recipes |
| Extensibility and ecosystem | 5 | 5 | Versioned manifest, install/list/remove/verify, provenance and revocation; community catalog still to populate |
| Multi-repository and enterprise operation | 4 | 5 | Harne8 boundary ratified and tested; durable orchestration/tenancy remain Harne8's job by design |
Detailed findings
1. Install, upgrade and local-first runtime — 5/5
Purpose: make governance easy to adopt without creating a hosted-service dependency.
Delivered now: a deterministic Homebrew formula and WinGet manifest
generator (pose release-package-manifests) driven by the release's own
checksums, wired strictly after every release verification step; a clean-host
CI matrix installing/doctoring/uninstalling through both channels on macOS and
Windows; pose doctor --fix (preview) and --fix --yes covering three
confined, idempotent repairs (pre-commit hook, .mcp.json, Claude skill
symlinks) reusing already-tested code paths; full unit coverage of
cmdUpgrade against a populated instance (real spec, real knowledge note, a
hand-edited managed file) proving dry-run non-mutation, schema-only apply and
idempotent reapply; a symlink-escape gap in managed directories closed via
ensureManagedDirSafe.
Also delivered this cycle: a field audit of pose update/pose install
against seven real, independently-owned repositories (not synthetic
fixtures) surfaced and closed 11 correctness/robustness defects — locale
handling was unreliable without --force; a plain update could leave an
old instance with broken references undetected by pose doctor (now two
new doctor checks: instance.config-completeness,
module-metadata.orphan-entries); a hand-edit outside an
instance-owned AGENTS.md/POSE.md section could be silently dropped (now
warned and consistently backed up); pose update without --force now
creates every directory the instance contract requires instead of a
hand-picked subset; and the embedded scaffold no longer leaks pose-dist's
own computed index/graph data into fresh instances. Verified against real
upgrades from four prior published releases (1.1.0, 1.0.0, 0.19.0, 0.18.2)
on every one of four consecutive real releases cut this cycle
(v1.4.0-v1.4.3).
Strength: installation and upgrade are no longer just tested in the abstract — they are proven against instances that already have real content in them, and now also against real, independently-owned repositories with their own pre-existing customizations and unrelated in-progress work, which is the scenario that actually breaks upgrade paths in practice.
Gap to ideal: the WinGet manifest generator is real and CI-tested, but
publication into winget-pkgs itself is a maintainer-reviewed submission
that has not yet been made; Scoop and Nix channels remain uncovered. Neither
is a mechanism gap — both are real follow-through steps documented as open
in pose-package-manager-distribution's own Final Report.
2. Spec lifecycle and closeout — 5/5
Purpose: prevent ambiguous work from starting and incomplete work from being declared done.
Delivered now: an in-spec requirement trace contract (grammar, parser,
lint gates, metrics) with a bidirectional MCP projection
(pose_requirement_trace) linking stable requirement IDs to the checks,
results and commits that satisfied them; an append-only amendment contract
(amendments.jsonl) with a pose amend command distinguishing material
changes from editorial acknowledgment, a deterministic hash-based closeout
gate, and an MCP projection (pose_spec_amendments).
Strength: POSE now closes the two gaps this document previously named explicitly — requirement-to-test/result traceability and structured change history for spec amendments — without weakening the human-review requirement for intent changes.
Gap to ideal: approval records remain a human act (a reviewer approving a PR), not a machine-readable signed attestation of who approved what spec change. This is a deliberate boundary, not an oversight — POSE's own model treats human judgment on intent as non-negotiable.
Benchmark: GitHub Spec Kit offers a rich SDD lifecycle, extensions, presets and workflows; OpenSpec is strong at lightweight brownfield change deltas and archive-to-source flow; Kiro integrates specs, steering and hooks into an agentic development service.
3. Task routing, workflows, rules and skills — 5/5
Purpose: translate task intent into the correct procedure, constraints and checks across agents.
Delivered now: compatibility frontmatter (pose_schema_range, clients,
capabilities) on all 11 shipped skills in both locales; pose skills-check
as a CI gate; pose_skills_check as an MCP tool; broken-link detection caught
one real defect during delivery, proving the gate exercises real content, not
a placeholder check.
Strength: the full Agent Skills contract is now continuously validated rather than assumed, and routing remains data — rules can evolve without copying every workflow.
Gap to ideal: a signed, versioned catalog with update/conflict handling for skills is now the generic extension-lifecycle mechanism described in finding 15, not a gap specific to this mechanism.
4. Dependencies, readiness and roadmaps — 4/5
Purpose: start only eligible work and expose planning order.
Delivered now: pose portfolio-projection reconciles dependency,
readiness, ownership and criticality across repositories, reusing the MCP
server's own project-authorization boundary; an additive xref: reference
grammar; explicit blocked/stale/unauthorized/unknown resolution
states so a reader always knows when a projection is out of date, persisted
as a revisioned, tombstoned report.
Strength: readiness and cross-repository planning now derive from versioned contracts and an explicit staleness signal, not board status or a manually maintained spreadsheet.
Gap to ideal: there is still no graphical impact/critical-path visualization or capacity/time-allocation view — deliberately: POSE stays a projection source, not a transactional scheduler. That visualization layer is Harne8's Portal, not the local engine's job.
5. Validation and structural integrity — 5/5
Purpose: replace subjective "looks done" decisions with repeatable checks.
Delivered now: a maintained stack catalog now covering Node.js, Go, Rust,
Java, Python (five package managers) and .NET, plus a read-only pose stacks
detection command; a canonical, versioned validation result model with
additive --json/--junit/--sarif emission; deterministic changed-scope
selection (--changed-from/--changed-to) over declared dependency edges with
a safe-execution fallback and an --explain trace; per-check timeout and
output-ceiling guardrails with process-group cancellation, plus an
isolation: "required" classification for checks that must run in the
Harness rather than locally; three docs-as-tests monorepo recipes (JS
workspace, declared dependency graph, mixed-language with a shared
high-criticality module) executed by a real test, not just documented.
Strength: every gap this document previously named by name — additional
stacks, standard result formats, timeouts/isolation, changed-scope selection,
monorepo recipes — is closed with executable evidence, not aspiration.
Also delivered this cycle: stack discovery is now a single shared detector
across pose index/validate/install/init (previously two
independently-drifting scanners), it classifies Android/Kotlin Gradle
modules distinctly from generic JVM ones, excludes synthetic
testdata/fixture content from discovery, and — found live on a real
repository whose vendored subtree was entirely gitignored — now respects
.gitignore instead of walking excluded trees as if they were the
project's own deliverable modules.
Gap to ideal: none identified against this mechanism's original scope. Future stack additions (e.g. Ruby, PHP) remain a routine catalog extension, not a structural gap.
6. Evidence, history and insights — 4/5
Purpose: preserve why a delivery was accepted and feed future decisions.
Delivered now: requirement trace (finding 2) links requirement IDs to the checks and commits that satisfied them; release artifacts carry SLSA provenance, CycloneDX SBOMs and Sigstore signatures (finding 11); Markdown reports, append-only JSONL history and MCP insights remain inspectable with ordinary Git. The v1.1.0/v1.2.0 review path additionally binds approval to an immutable semantic/source bundle while keeping the attestation append-only and outside the reviewed digest.
Strength: the traceability gap this document previously called out by name — "link requirement IDs to checks and commits" — is closed, release evidence carries real cryptographic provenance, and closeout review now has a stable subject/attestation boundary instead of a self-invalidating digest.
Gap to ideal: cryptographic provenance covers release artifacts and optional externally signed review envelopes, not every local report or closeout event. Local bundle attestations capture a reviewer/execution alias and exact subject digest, but remain integrity-protected by Git rather than requiring an asymmetric signature.
Benchmark: SLSA defines progressive build provenance guarantees, now applied to every POSE release artifact. CycloneDX defines interoperable SBOM media types and predicates, also now applied. Per-spec evidence signing would be a POSE-specific extension of the same idea, not something either standard covers directly.
7. Follow-ups and recurrence — 5/5
Purpose: stop residual work and repeated failures from disappearing into free text.
Delivered now: an inline ownership/SLA contract for follow-ups (syntax,
parser, closeout gate, projections, opt-in blocking) with the live backlog
migrated to owned entries; an intervention registry
(interventions.jsonl) feeding a deterministic before/after
effectiveness projection with verdicts and explicit data-quality warnings,
plus opt-in duration/cost telemetry.
Strength: POSE can now answer not just "what follow-ups are open" but "who owns them, by when" and "did the systemic fix we shipped actually reduce recurrence" — closing this document's two previously named gaps in full.
Gap to ideal: none identified against this mechanism's original scope.
8. Operational knowledge — 4/5
Purpose: preserve reusable context without creating permanent, ownerless documentation.
Delivered now: a stable knowledge:<slug> citation contract with a
dangling-reference gate; a derived usage projection
(knowledge-usage) honoring TTL immutability, so a reader can see when
governed knowledge actually influenced work rather than trusting that it was
read; deterministic, explainable, sensitivity-filtered advisory retrieval
(knowledge-suggest) with pre-retrieval scoping.
Strength: knowledge now has both decay/accountability by design (prior assessment) and consumption traceability (this delivery) — the two halves of "does this knowledge base actually get used" are both answered.
Gap to ideal: retrieval is lexical similarity over already-tested primitives, not embedding/LLM-based semantic search, and there is still no external identity/RBAC mapping for who is allowed to see sensitive knowledge beyond POSE's own sensitivity field.
9. MCP and agent interoperability — 5/5
Purpose: expose governance consistently to any MCP-capable agent.
Delivered now: a versioned golden catalog fixture
(testdata/tool-catalog.golden.json) freezing the exact tools/list payload
— 50 tools (47 POSE tools + 3 optional reporters) — with bijection and
negative-path tests against source registry, runtime and documentation; a
uniform project_id schema across every
multi-root tool with typed ProjectUnknownError/ProjectAmbiguousError and
structured error_code fields; opaque cursor pagination
(cursor/limit/next_cursor) on all four pose_list_* tools, fully
additive; a deterministic tie-order fix in ListReports.
Strength: the catalog drift this document previously flagged by name
(pose_validate in the ADR vs. no matching tool) is structurally impossible
to reintroduce now — the golden fixture and bijection tests fail CI the
moment source, runtime and docs disagree.
Gap to ideal: none identified against this mechanism's original scope. Resources/prompts remain unused because no current governance use case needs them, consistent with the prior assessment's own caution against overbuilding.
Benchmark: the MCP tools specification defines schema-based discovery, pagination and invocation and recommends human control over tool use — POSE's catalog now demonstrably conforms.
10. Policy, identity and audit — 4/5
Purpose: authorize every remote governance call within project and run scope.
Delivered now: a digest-pinned, identity-gated, idempotent
validation-orchestration state machine
(pose_validate_request/approve/submit/status/cancel) requiring explicit
approval before untrusted execution; audit log fields bounded against
oversized caller-supplied identity values (truncateForAudit), closing a
log-volume-abuse surface without touching the auditor's documented purpose
of recording who invoked what.
Strength: the request/approve/submit split gives policy a real intervention point before execution, not just an allow/deny log line after the fact.
Gap to ideal: asymmetric workload identity or SPIFFE integration, external secret management, TLS deployment guidance, rate limits, audit export and policy bundle/versioning remain entirely unaddressed — no roadmap in this portfolio targeted them. This is the mechanism with the largest gap remaining relative to its own prior assessment.
11. CI, release and supply-chain trust — 5/5
Purpose: make governance blocking and distribute a verifiable engine.
Delivered now: keyless Sigstore signing of every release artifact with
offline-verifiable bundles and a pinned issuer/identity policy; per-archive
CycloneDX SBOMs with schema and direct-dependency validation gates; SLSA v1
provenance attestation with a stated Build L2 claim and documented L3
limitation; an independent Verify release workflow running in a clean
environment with layered authentication (checksum, signature, SBOM,
provenance) before any execution; a versioned compatibility.json
(engine/schema/upgrade pairs, support policy) generating a
compatibility-report.md gate in CI; a placeholder-free public install
contract for Linux/macOS/Windows; the security workflow (CodeQL, govulncheck,
gitleaks, dependency review) and an OpenSSF Scorecard workflow, both
confirmed green this cycle after fixing a stale Go toolchain (govulncheck),
a test-fixture false positive (gitleaks) and a CodeQL build-mode
misconfiguration (switched to autobuild).
Strength: every gap this document previously named by name — signatures, SBOM, provenance, Scorecard, dependency/secret/static-analysis scanning, public placeholders — is closed with running, green CI evidence, not a documented intention.
Gap to ideal: the prior gap named here — "a real N-minus-1 comparison is unexercised until a second real published release exists" — is closed. Four consecutive real releases were cut, published and independently verified this cycle (v1.4.0 through v1.4.3), each with a bit-identical independent rebuild and each exercising real upgrade paths from four previously-published versions (1.1.0, 1.0.0, 0.19.0, 0.18.2) against pinned, checksum-authenticated prior artifacts — not simulated. Three of the four releases (v1.4.1-v1.4.3) shipped same-day follow-up fixes for defects found auditing the immediately preceding release against real, independently-owned external repositories, which is itself evidence the release-to-fix-to-release loop works end to end under real conditions, not only in isolation. A higher SLSA build level, broader OpenSSF Scorecard improvement and upstream package-channel automation remain hardening work, not missing evidence for the current release contract.
12. Import and adoption interoperability — 4/5
Purpose: let teams adopt POSE without discarding existing SDD work.
Delivered now: three checked-in, executable adoption kits
(examples/brownfield-kits/{direct-adoption,spec-kit-import,openspec-import}/)
with staged visibility→adoption→blocking-gate READMEs, each verified
end-to-end by a dedicated test against a real, intentionally-imperfect
fixture (not a pristine synthetic one).
Strength: the prior gap — "publish mapping fixtures" — is closed with real, tested, checked-in examples rather than documentation prose, and the kits deliberately preserve real migration friction instead of hiding it.
Gap to ideal: custom source schemas through a plugin mechanism and a read-only diff/reconciliation mode remain open. Bidirectional sync deliberately remains out of scope — two lifecycle authorities create ambiguity POSE should not resolve implicitly.
13. Metrics and observability — 5/5
Purpose: show whether governance improves delivery outcomes and product adoption.
Delivered now: pose record-deployment/record-incident for
quality-gated event ingestion; pose dora-metrics computing all five current
DORA metrics for an explicit production environment, with deployment rework
rate and recovery restricted to deployment-caused incidents;
pose adoption-metrics deriving activation, time-to-first-gate, retention
and task-success from existing spec/history data; automatic pose usage and
pose_usage analytics for tool calls, semantic outcomes, latency and
structured finding lifecycle without manual counters; pose events-housekeeping
for delivery-event retention; opt-in OpenTelemetry traces and metrics (stable SDK,
OTLP/HTTP) plus a trace-correlated, redacted structured logger wired through
every MCP tools/call, with graceful startup/shutdown including
SIGINT/SIGTERM handling.
Strength: usage, adoption and delivery are three explicit planes. Product activity is not blended with DORA into a false causal claim, and finding counts come from structured gates rather than agent-maintained counters or stderr line parsing.
Gap to ideal: human confirmation of an observed finding as valid,
wont-fix or false-positive remains an owned follow-up. Logs are a local
structured writer rather than OTLP-exported, and DORA ingestion is manual or
CI/webhook-driven rather than inferred — both are stated boundaries.
14. Documentation, localization and diagnostics — 5/5
Purpose: shorten time to first governed delivery and make failures actionable.
Delivered now: a real, previously undetected locale-parity bug fixed
(English default templates that were actually Portuguese, with no pt-BR
translation on file); a self-inspecting documented-commands contract test
that reads the CLI's own dispatch table instead of duplicating it; all 13
docs-site pages classified by Diátaxis type with a visible
version-applicability line; a docs security scan reusing the skills
conformance patterns; pose doctor --fix turning diagnosable failures into
guided, confined, idempotent remediation instead of prose instructions.
pose init/pose install now excerpt a brownfield target's own
README.md/CLAUDE.md into AGENTS.md's "Project context" section on
first install instead of a generic placeholder. A real field audit found and
fixed a second class of locale defect beyond the original parity bug: an
explicit --locale request could be silently ignored, or could produce a
duplicated (not switched) manual on an already-installed instance; both are
now fixed, including detecting a locale switch and warning when content
outside instance-owned sections would be dropped. The same audit also
found pose check's own summary line was unconditionally Portuguese
regardless of locale for every direct invocation, not only the one internal
call the fix originally targeted — now corrected.
Strength: documentation now has the same kind of executable guarantee POSE demands of everything else — a doc claiming a command exists is verified against the CLI's real dispatch table, not maintained by hand, and locale correctness is now audited against real multi-locale installations, not only unit fixtures.
Gap to ideal: none identified against this mechanism's original scope.
15. Extensibility and ecosystem — 5/5
Purpose: let teams add domains and integrations without maintaining a fork.
Delivered now: an extension.json manifest contract with path
confinement, permission whitelisting, revocation and provenance; pose
extension install/list/remove/verify — dry-runnable, consent-gated,
transactional. pose extension install <extension-id> (v1.4.0) now also
resolves the ID against the latest published GitHub release's signed
assets and installs it through the same signature-verified pipeline — no
local directory required — and accepts a --locale flag so an extension
package can carry localized content (pose-rule-backend-go and
pose-rule-frontend-react now ship pt-BR variants).
Strength: every element this document previously named as the completion benchmark — versioned manifests, compatibility constraints, discovery, install/update/removal, conflict handling, provenance, a catalog mechanism — is delivered.
Gap to ideal: the lifecycle and online-resolution mechanisms are
complete; a populated third-party or community extension catalog is not —
this is an ecosystem adoption gap (will grow with usage), not a missing
mechanism. Only pose-rule-kubernetes is signed and published this way
today; pose-rule-backend-go/pose-rule-frontend-react remain
local-directory-installable only until the release workflow signs and
publishes them too. GitHub Spec Kit's populated extensions/presets/bundles
remain the useful comparison for that adoption curve, not for the mechanism
itself.
16. Multi-repository and enterprise operation — 4/5
Purpose: preserve the same governance model across many teams and projects.
Delivered now: a ratified five-component responsibility table mapping
POSE/Conductor/Harness/GraphForge/Portal to already-tested surface;
pose reconcile-evidence, an identity-bound, append-only Harness-result
reconciliation contract rejecting silent mutation with tenant-scoped
retention; an executable end-to-end test proving offline degradation (not
just a documentation claim) when Harne8 is absent; cross-repository
portfolio projection (finding 4); advisory semantic suggestions across
knowledge, follow-ups and recurrence patterns with rationale and sensitivity
filtering (pose semantic-suggest).
Strength: the open-core/Harne8 boundary is no longer just an architectural intention — it is a ratified, citable table plus a tested contract proving the core keeps working when Harne8 is not present.
Gap to ideal: centralized discovery UX, SSO/RBAC, tenant isolation, durable orchestration, approvals, portfolio visualization, policy distribution and support operations remain Harne8's responsibility by design, not the local engine's. Keeping them out of the CLI is the point, not a shortfall — but it is also why this mechanism cannot honestly score higher from pose-dist's side alone.
Priority improvement plan
Every P0 and P1 item from the 2026-07-18 assessment is delivered; the P2 item this document previously left explicitly to Harne8 (durable orchestration, visual operation) is unchanged as an intentional boundary. The plan below covers what is genuinely still open, drawn from the residual risks and follow-ups each delivering spec recorded in its own Final Report.
P0 — close real, spec-identified follow-through gaps
- Submit the generated WinGet manifest to
winget-pkgs(the generator and CI matrix are done; the maintainer-reviewed submission is not).
The prior P0 item 2 (exercise a real N-minus-1 comparison once a second real published release exists) is delivered — see finding 11.
P1 — harden what no roadmap in this portfolio targeted
- Add workload identity (SPIFFE or equivalent), external secret management and TLS deployment guidance for remote MCP deployments.
- Add rate limiting, audit export and policy bundle/versioning to the OPA-based policy layer.
- Add a plugin mechanism for custom import source schemas and a read-only diff/reconciliation mode for already-adopted repositories.
- Add OTLP log export once the OpenTelemetry Logs SDK reaches a stable release (currently a documented, deliberate wait, not an open task).
P2 — grow ecosystem adoption on top of delivered mechanisms
- Seed the extension catalog with real third-party or community entries — the install/update/removal/provenance mechanism is done; population is not.
- Evaluate a real embedding/LLM-backed provider for
pose semantic-suggestwhere one can be safely configured and tested, reducing (not eliminating) the residual risk its own spec names for lexical similarity. - Add Scoop and Nix package-manager channels alongside the delivered Homebrew/WinGet pair.
- Continue building Harne8's durable orchestration, visual portfolio
operation, tenant-scoped policy distribution and support tooling on top
of the now-ratified open-core boundary and
pose reconcile-evidencecontract — this remains Harne8's roadmap, not pose-dist's.
Reassessment protocol
Re-run this assessment at each minor release:
- Pin the release commit and list evidence commands.
- Score only behavior that is implemented and verified.
- Link each score increase to a check, report or public artifact.
- Record benchmark changes; external products evolve.
- Keep historical assessments so product progress is visible.
Do not collapse the table into one percentage. The purpose is to choose the next highest-value constraint, not to optimize a vanity score.