consensus-guard-core

Open-source Consensus.Tools skill for governed AI decisions with board-native artifacts, strict JSON contracts, and deterministic policy behavior.

Security Scan

The package is internally coherent with its stated purpose as a local, deterministic policy primitive library — no credentials or network access, and filesystem writes are confined to a configurable state root — though there are a few minor metadata/integration inconsistencies to be aware of.

Purpose & Capability

The name/description (policy primitives for consensus guards) align with the code and SKILL.md: deterministic vote aggregation, reputation updates, idempotency, schema helpers, and board state helpers. The package depends on @consensus-tools/consensus-tools which matches its role as part of a consensus stack. Minor inconsistency: SKILL.md lists runtime binaries ('node', 'tsx') and env vars used for state paths while the registry metadata claims no required binaries/env vars.

Instruction Scope

Runtime instructions and code stay within the stated scope: no model/provider calls, no outbound network in the core, and filesystem writes only occur when callers invoke write helpers. The resolveStatePath implementation confines state files under a configured root, preventing directory traversal. The code does import internal storage/engine helpers from @consensus-tools/consensus-tools, which is expected for tight integration but couples this package to that dependency's internal layout.

Install Mechanism

There is no platform install spec (instruction-only), but the SKILL.md and package.json show normal npm usage (npm i consensus-guard-core). The code and package-lock are included in the bundle; dependencies are semver-pinned. No external download URLs or unusual installers are used. Consumers should still audit transitive dependencies (e.g., optional native deps like better-sqlite3 in the dependency tree).

Credentials

No API credentials are requested and none appear in code. The package reads two environment variables for configuration (CONSENSUS_STATE_FILE and CONSENSUS_STATE_ROOT) but these are optional and default to safe values; the registry metadata did not declare them as required, which is a metadata mismatch but not a privilege escalation. No secrets/external tokens are requested or accessed.

Persistence & Privilege

The skill writes artifacts to local board/state files when callers call write helpers. The state path resolution enforces confinement under a configurable root and hashes absolute paths into an _abs directory, reducing risk of writing to arbitrary system locations. The skill does not request permanent 'always' inclusion and does not modify other skills' configurations.

Assessment

This package appears to do what it claims: local deterministic policy primitives that read/write a configurable state directory and require no API keys or network. Before installing, confirm: 1) you are comfortable giving it a dedicated state directory (set CONSENSUS_STATE_ROOT to a non-privileged folder), 2) you or your supply-chain process audit the @consensus-tools/consensus-tools dependency and other transitive packages (native optional deps like better-sqlite3 may be pulled in by consumers), and 3) consumers import the stable package API (not fragile internal paths). The only noteworthy inconsistencies are metadata vs SKILL.md (runtime binaries and optional env vars) and the library’s direct imports of internal files from @consensus-tools — these are maintainability/supply-chain risks, not indicators of malicious behavior. Run npm test in an isolated environment and review the dependency tree if you require higher assurance.

consensus-guard-core is the common policy engine behind the Consensus guard ecosystem.

What this skill/package provides

• unified hard-block taxonomy
• deterministic aggregateVotes() policy function
• deterministic reputation update rules with clamping
• idempotency key generation for retry-safe execution
• strict-schema unknown-field rejection helpers
• indexed board read helpers for scalable artifact lookup

Why this matters

Without a shared core, every guard drifts into incompatible policy logic. This package keeps behavior consistent, replayable, and comparable across domains.

Ecosystem role

consensus-guard-core is consumed by publish/support/merge/action guards and should be treated as policy infrastructure, not an end-user workflow skill.

Benefits for LLM orchestration

• lower integration drift
• consistent decision semantics across workflows
• easier auditing and cross-skill analytics

Runtime, credentials, and network behavior

• runtime binaries: node, tsx
• network calls: none in this package's core decision/path helpers
• credentials: none required by this package
• environment config read by this package: CONSENSUS_STATE_FILE, CONSENSUS_STATE_ROOT (for board/state path resolution)
• filesystem writes: board/state artifacts under the configured consensus state path when callers use write helpers (for example writeArtifact)

Dependency trust model

• consensus-guard-core is a first-party consensus package
• versions are semver-pinned in package.json for reproducible installs
• this skill does not request host-wide privileges and does not mutate other skills
• note: dependency trees should be audited separately by consumers for transitive packages

Install

npm i consensus-guard-core

Quick start

npm test

Import contract

Use the package root import (stable public API):

import { aggregateVotes, writeArtifact, resolveStatePath } from 'consensus-guard-core';

Do not import internal paths like consensus-guard-core/src/index.mjs in dependent skills.

Tool-call integration

This skill is wired to the consensus-interact contract boundary (via shared consensus-guard-core wrappers where applicable):

• readBoardPolicy
• getLatestPersonaSet / getPersonaSet
• writeArtifact / writeDecision
• idempotent decision lookup

This keeps board orchestration standardized across skills.

Invoke Contract

This skill exposes a canonical entrypoint:

• invoke(input, opts?) -> Promise<OutputJson | ErrorJson>

invoke() is primitives-only and delegates to a caller-provided handler. It does not perform persona generation or model/provider calls.

See also: SECURITY-ASSURANCE.md for threat model, runtime boundaries, and hardening guidance.