Tenetora

Install

Install or upgrade Tenetora. No install command is offered until the public sources are verified.

Your operating system could not be detected; select it manually to show the install command.

Python requirement

>=3.9

First install default scope

global

Upgrade without a scope

existing-only

Non-interactive default language

en

Trust and restart：Restart the native plugin host after updates; review /hooks after first install or hook changes.

// the-failures

The failures it governs

Consider an API change made across several modules with two coding agents:

1. 01The first agent reads AGENTS.md and a local rule file.
2. 02The second agent reads a different instruction set after context compaction.
3. 03A copied issue description contains an unsafe instruction.
4. 04The change affects a shared schema, but no one records the consumers.
5. 05A focused unit test passes while the integration path is broken.
6. 06The final report says “done”, but no one can reproduce the verification.

The problem is not that the agents cannot write code. The problem is that the work has no durable control surface.

// governance-flow

One governed work path

One project record flows through five stages — the same pipeline the toolchain enforces; skipping any stage changes what the conclusion means:

1. 01 Recordrules, facts, decisions, and evidence live in .tenetora/, current guidance separated from history.
2. 02 Routeeach task loads only the rule slice for its context, leaving consumption evidence.
3. 03 Guardexternal input, rule changes, commits, and completion claims pass deterministic checks before acting.
4. 04 Observeruntime observation, review, and change-impact evidence recorded as-is — a file existing is never “active”.
5. 05 Provea completion claim binds the full verification command, the current goal, and the worktree state.

// where-it-fits

What it is not

Tenetora operates beside, not instead of, other engineering systems. The difference is which layer is governed:

• What it ownsWhat Tenetora governs
• Spec / SDD toolsDescribe what should be builtGoverns which project context the agent consumes, which risky boundaries are checked, and which evidence supports the final claim
• Rules files & prompt templatesRemind the agent to follow rules and run testsKeeps rules in one project record, distinguishes a partial check from the declared full command, and rejects stale evidence
• Plain hooksTrigger fixed actions inside one toolProvides shared CLI semantics and an evidence model across tools, reporting each platform’s real runtime ceiling
• CIRejects a bad commit after it is createdAlso governs the earlier model workflow and the local action that creates the commit
• Issue trackersRecord team work and product decisionsRecords execution-level decision reasons, action boundaries, and verification evidence

// real-scenarios

Real engineering situations

Eleven concrete situations where governance changes the outcome. Each observable result comes from an actual product mechanism:

1. Several tools work on one repositoryEach host reports its effective skill/plugin/runtime source; another conversation cannot silently complete the first one’s alignment.
2. Conversations run in parallelAlignment and completion evidence are owner-bound; a later conversation cannot inherit an earlier one’s active goal or claim.
3. One conversation switches modelsEach model run is recorded as a separate execution attempt; the alignment session, goal, and owner stay unchanged.
4. Another model continues after a rate limitA rate-limited attempt does not close the alignment; the next model appends an attempt instead of creating a second goal.
5. A long task resumes after interruptionBounded loop state records the goal, exit criteria, and next prompt; repeated blockers stop the loop, and other sessions cannot take over.
6. An external report carries prompt injectionPrompt guard classifies the content before it is followed; a report cannot grant itself local execution or rule-edit authority.
7. A global install meets a scratch workspaceA directory without .tenetora/ or .harness/ stays silent — no injected context, no gates; governance is enabled per project.
8. A project depends on local environment filesPaths are registered without storing contents; doctor/status discover a missing path, the commit guard keeps them out of staging, and PreToolUse denies high-confidence destructive operations where the host supports it.
9. A shared API, hook, or plugin contract changesChange-impact preflight records the contract and its consumers before editing and rescans after; commit checks distinguish recorded from unrecorded edits.
10. A local test is treated as task completionA completion claim binds the full declared command and the worktree fingerprint; a newer failure or a changed worktree invalidates old evidence.
11. One machine upgrades several projectsAn existing-only upgrade refreshes registered surfaces only, with previewable discovery; legacy directories of unclear ownership stay untouched.

Per-item mechanics, evidence, and boundaries: see Concepts