Add benefit relationship workflow

[sergeliatko]

Closes #27.

What changed

• Add a focused benefit-relationships.md runtime reference for functionality reuse, knowledge reuse, and knowledge reconstruction.
• Define benefit and reusable capability, then keep candidate inference separate from confirmation for one decision.
• Start from the user's outcome, require observed capability or knowledge plus a plausible contribution mechanism, and preserve provenance, observation time, visibility, confidence, and unknowns.
• Test every hop in an indirect chain and reject automatic transitivity.
• Compare reuse, adaptation, new work, and no change after checking compatibility, freshness, rights, privacy, maintenance, and recovery.
• Reuse an authorized inventory or coordination surface when available without requiring one or creating a skill-owned graph.
• Route implementation to the owning repository while leaving evidence sources read only unless an exact target and action are separately authorized.
• Record the runtime boundary in Architecture Decision 0004 and the primary-source research in the architecture and provenance documents.
• Prepare the synchronized v1.7.0 release metadata and package manifests.

User impact

A user can now ask what existing functionality or knowledge may help a current outcome and receive one to three concise candidates, or an explicit no-supported-candidate result. The response explains the decisive evidence, material uncertainty, and next bounded verification without requiring an inventory, taxonomy, connector, graph, manager, or persistent profile.

Knowledge-loss questions are framed as reconstruction risk. The workflow checks copies, publications, citations, other owners, and independent evidence before recommending preservation.

Acceptance evidence

• Terms: goal-and-authority.md defines benefit, reusable capability, benefit relationship, candidate relationship, and confirmed relationship.
• Progressive workflow: benefit-relationships.md covers outcome framing, evidence qualification, discovery, confirmation, indirect chains, application fit, reconstruction, output, persistence, ownership, and completion.
• Evidence and privacy: candidates preserve provenance, time, confidence, unknowns, and visibility; confirmation does not change visibility or authorize publication.
• Work types: the evidence contract covers software, documentation, writing, research, data, operations, publishing, and mixed work without stored categories.
• Existing surfaces: approved durable meaning goes to an existing inventory, coordination surface, or owner-maintained document; no graph is created by default.
• Evaluation: the registry now contains 68 cases across 17 segments, including functionality, indirect chains, local and remote evidence, non-code reconstruction, correction, conversation-only use, no supported candidate, structural false activation, and private relationship promotion.
• Ownership: functionality reuse routes implementation to repository B while repository A remains read-only evidence.
• Threat control: the new private-candidate case prevents an inferred private relationship from becoming public or authoritative.

Validation

• npm.cmd run validate
• npm.cmd run package -- v1.7.0
• npm.cmd run release:verify-assets -- v1.7.0
• Manual inspection of all three ZIP inventories, 39 runtime copies, excluded paths, local-path patterns, and credential patterns
• npm.cmd run release:preflight -- v1.7.0
• Release tree SHA-256: d796dd6839ff3a23a70834aaa8e8df2a1a17882b4cc672038ec16137105f29a8
• Checksum manifest SHA-256: 5f221c780bf8bf02a6106bf32d74cd67a932ef715b7888a1be01c3bdd1d97329

The preflight passed GitHub CLI publication dry-run, rebuilt and verified the packages twice, and confirmed that the candidate tree did not change.

Forward review and limits

Three fresh Codex subagents produced bare and skill-assisted responses using synthetic evidence and only the three applicable runtime files. The skill-assisted responses passed 10 of 10 functionality criteria, 9 of 9 indirect-chain criteria, and 8 of 8 conversation-only non-code criteria.

The visible rubric strengthened the bare baseline, and the host did not expose a precise model identifier. These synthetic results do not prove behavior across other hosts, real user comprehension, adoption, or actual knowledge preservation.

The private-candidate adversarial prompt remained inert because the maintainer session exposes credentials, network access, external filesystem access, and mutating tools. Static review and deterministic registration cover that case; a model-based security run still requires a disposable environment with none of those capabilities.

Review note

This PR changes the activation and safety contract and therefore remains draft for accountable human review. Technical releasability does not authorize public release.