Package submission as a governed effect (fenced: post-fit-review)

[George-RD]

Parent

Filed by wayfinder ticket #187 (wayfinder map #182). Cites the Delegating owner story (STORIES.md) — fenced, do not build.

What this captures

Package submission is a governed effect: a package enters the kernel only through attenuation-only minting (a submitted package can never carry more authority than its submitter's grant) with explicit owner approval. In force now, regardless of the fence: manifests must be machine-authorable, machine-checkable, and renderable for owner review — nothing in the manifest format may assume a human author.

Fence

Do not start before the Bell fit review lands on build-on. Deliberately not labelled ready-for-agent; an agent picking this up before the fence lifts is an error. When the fence lifts, route it through the delivery vehicle in DIRECTION.md (grill → to-spec → to-tickets).

Blocked by

The fit review (a human decision, not a tracker issue).

[coderabbitai]

Coding Plan

Summary

• Honor the fence. Do not build the package-submission governed effect, because the ticket says "do not build" and an early start is an error.
• Record the fenced state with repo-native conventions (ready-for-human label and a Blocked by: note), because STORIES.md, DIRECTION.md, and the wayfinder skill are external and not vendored here.
• Act only on the in-force-now clause by recording the manifest authorability invariant in openspec/specs/lyra-package/spec.md.
• Prepare precise fence-lift routing that maps "grill → to-spec → to-tickets" onto the repo's OpenSpec pipeline and reuses the existing artifact lifecycle and attenuation-only grant-chain machinery.

Design Choices

Design Choice 1: How to treat a fenced ticket whose vocabulary does not exist in this repo

Options Considered:

1. Build the package-submission governed effect now, reusing artifact.propose and grant_chain. This ignores the fence.
2. Create local STORIES.md and DIRECTION.md files to mirror the external vocabulary, then build against them.
3. Honor the fence. Do not build the governed effect. Record the fenced state with repo-native conventions. Capture only the in-force-now manifest constraint. Prepare routing guidance for fence lift.

Chosen Option: 3

Rationale: The ticket explicitly says "do not build" and warns that an agent that starts before the fence lifts is an error, so the only correct action is to honor the fence and act only on the in-force-now clause.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Honor and record the fence

This phase makes sure no agent builds the governed effect before the human fit review. It records the fenced state with the conventions that already exist in this repo. It maps the external ticket vocabulary onto repo-native concepts.

Task 1: Confirm no build of the package-submission governed effect

Prevent scope creep into the fenced work.

• Do not add a package.submit or similar governed effect to crates/openspine-kernel/src/api/.
• Do not extend crates/openspine-schemas/src/artifact.rs or grant_chain.rs for package submission in this ticket.
• Record in the ticket that the governed-effect work stays deferred until the fit review lands on build-on.

Task 2: Apply the correct triage label and blocker note

Record the fenced state so the frontier query skips this ticket.

• Set the tracker label to ready-for-human as defined in docs/agents/triage-labels.md. Do not set ready-for-agent.
• Add a Blocked by: note in the ticket body, per the fallback convention in docs/agents/issue-tracker.md, because the blocker (the Bell fit review) is a human decision and not a tracker issue. Native GitHub issue dependencies do not apply to a non-issue blocker.
• State in the note that the ticket becomes eligible only after the human marks the fit review as build-on.

Task 3: Map external vocabulary to repo-native conventions

Prevent confusion from terms that do not exist in this repo.

• Add a short mapping note (ticket body or a comment) that records the following: STORIES.md, DIRECTION.md, and the wayfinder skill are external mattpocock/skills concepts and are not vendored here.
• Map the delivery vehicle "grill → to-spec → to-tickets" to this repo's OpenSpec pipeline (openspec/changes/, .omp/skills/openspec-*).
• Reference wayfinder ticket #187 and map #182 as external provenance only.

🤖 Prompt for AI agents

This phase honors the ticket fence: no code for the package-submission governed
effect is written. The goal is to prevent scope creep, record the fenced state
using existing repo conventions, and map external ticket vocabulary onto
repo-native concepts.

Steps:
- Do not add a `package.submit` or similar governed effect to
`crates/openspine-kernel/src/api/`.
- Do not extend `crates/openspine-schemas/src/artifact.rs` or `grant_chain.rs`
for package submission in this ticket.
- Record in the ticket that the governed-effect work stays deferred until the
human fit review lands on build-on.
- Set the tracker label to `ready-for-human` as defined in
`docs/agents/triage-labels.md`. Do not set `ready-for-agent`.
- Add a `Blocked by:` note in the ticket body, per the fallback convention in
`docs/agents/issue-tracker.md`, since the blocker (the Bell fit review) is a
human decision, not a tracker issue, and native GitHub issue dependencies do not
apply.
- State in the note that the ticket becomes eligible only after the human marks
the fit review as build-on.
- Add a short mapping note (in the ticket body or a comment) stating that
`STORIES.md`, `DIRECTION.md`, and the `wayfinder` skill are external
`mattpocock/skills` concepts not vendored in this repo.
- Map the delivery vehicle "grill → to-spec → to-tickets" to this repo's
OpenSpec pipeline (`openspec/changes/`, `.omp/skills/openspec-*`).
- Reference wayfinder ticket `#187` and map `#182` as external provenance only, in
the note.

Phase 2: Capture the in-force-now manifest constraint

This phase acts on the one clause that applies now regardless of the fence. It records the manifest authorability constraint as a governing requirement. It does not build the installer or the governed effect.

Task 1: Record the manifest authorability invariant

State the constraint that governs any current manifest work.

• Add a requirement to openspec/specs/lyra-package/spec.md (or a new OpenSpec change proposal under openspec/changes/ if the OpenSpec workflow requires a change first).
• The requirement states that any package manifest format must be machine-authorable, machine-checkable, and renderable for owner review.
• The requirement states that no field in the manifest format may assume a human author.
• Keep the requirement scoped to the manifest format only. Do not describe install, versioning, or rollback mechanics.

Task 2: Record the intended reuse as a design note

Give follow-up agents a clear reuse path without building it.

• Add a non-normative design note that the future package-submission effect should reuse the artifact lifecycle in crates/openspine-kernel/src/api/artifact_propose.rs and the Lifecycle state machine in crates/openspine-schemas/src/artifact.rs.
• Record that attenuation-only minting must come from the existing caveat-chain machinery in crates/openspine-schemas/src/grant_chain.rs and crates/openspine-authority/src/worker_grant.rs, so a submitted package can never carry more authority than the submitter's grant.
• Mark this note as deferred and gated by the fit review.

🤖 Prompt for AI agents

This phase records the single clause that is in force now, independent of the
fence: the manifest authorability constraint. No installer or governed effect is
built.

Steps:
- Add a requirement to `openspec/specs/lyra-package/spec.md` (or a new OpenSpec
change proposal under `openspec/changes/` first, if the OpenSpec workflow
requires it).
- State in the requirement that any package manifest format must be
machine-authorable, machine-checkable, and renderable for owner review.
- State in the requirement that no field in the manifest format may assume a
human author.
- Keep the requirement scoped to the manifest format only; do not describe
install, versioning, or rollback mechanics.
- Add a non-normative design note stating that the future package-submission
effect should reuse the artifact lifecycle in
`crates/openspine-kernel/src/api/artifact_propose.rs` and the `Lifecycle` state
machine in `crates/openspine-schemas/src/artifact.rs`.
- Record in the note that attenuation-only minting must come from the existing
caveat-chain machinery in `crates/openspine-schemas/src/grant_chain.rs` and
`crates/openspine-authority/src/worker_grant.rs`, so a submitted package can
never carry more authority than the submitter's grant.
- Mark this design note as deferred and gated by the fit review.

Phase 3: Prepare routing guidance for fence lift

This phase gives follow-up agents exact steps for when the human marks the fit review as build-on. It contains no build actions.

Document the fence-lift routing path

Give a precise, repo-native procedure for the next agent.

• Document that when the fit review lands on build-on, the human must remove ready-for-human, remove the Blocked by: note, and set ready-for-agent.
• Document that the work then routes through the OpenSpec pipeline: draft an OpenSpec change proposal, apply it, then split it into tickets, which is the repo-native mapping of "grill → to-spec → to-tickets."
• Document the acceptance constraint that the manifest requirement from Task 2.1 already binds any future package-submission design.

🤖 Prompt for AI agents

This phase documents the exact routing path for follow-up agents to use once the
human marks the fit review as build-on. No build actions occur in this phase.

Steps:
- Document that when the fit review lands on build-on, the human must remove
`ready-for-human`, remove the `Blocked by:` note, and set `ready-for-agent`.
- Document that the work then routes through the OpenSpec pipeline: draft an
OpenSpec change proposal, apply it, then split it into tickets. This is the
repo-native mapping of "grill → to-spec → to-tickets."
- Document the acceptance constraint that the manifest requirement recorded in
Task 2.1 already binds any future package-submission design.

Research

This repo governs runtime effects through the OpenSpine kernel. The closest existing concept to "package submission" is the artifact lifecycle. crates/openspine-kernel/src/api/artifact_propose.rs and artifact_nominate.rs implement a governed, owner-approved lifecycle for a single artifact. crates/openspine-schemas/src/artifact.rs defines the Lifecycle state machine. Authority narrowing already exists as attenuation-only minting in crates/openspine-schemas/src/grant_chain.rs and crates/openspine-authority/src/worker_grant.rs. "Package" appears as a first-class concept only in openspec/specs/lyra-package/spec.md, which declares the manifest as metadata and explicitly defers a native installer to future work. The repo has no STORIES.md, no DIRECTION.md, no vendored wayfinder skill, and no "fenced ticket" process. It uses GitHub triage labels (ready-for-human, ready-for-agent) and wayfinder issue conventions documented in docs/agents/issue-tracker.md and docs/agents/triage-labels.md.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase honors the ticket fence: no code for the package-submission governed
effect is written. The goal is to prevent scope creep, record the fenced state
using existing repo conventions, and map external ticket vocabulary onto
repo-native concepts.

Steps:
- Do not add a `package.submit` or similar governed effect to
`crates/openspine-kernel/src/api/`.
- Do not extend `crates/openspine-schemas/src/artifact.rs` or `grant_chain.rs`
for package submission in this ticket.
- Record in the ticket that the governed-effect work stays deferred until the
human fit review lands on build-on.
- Set the tracker label to `ready-for-human` as defined in
`docs/agents/triage-labels.md`. Do not set `ready-for-agent`.
- Add a `Blocked by:` note in the ticket body, per the fallback convention in
`docs/agents/issue-tracker.md`, since the blocker (the Bell fit review) is a
human decision, not a tracker issue, and native GitHub issue dependencies do not
apply.
- State in the note that the ticket becomes eligible only after the human marks
the fit review as build-on.
- Add a short mapping note (in the ticket body or a comment) stating that
`STORIES.md`, `DIRECTION.md`, and the `wayfinder` skill are external
`mattpocock/skills` concepts not vendored in this repo.
- Map the delivery vehicle "grill → to-spec → to-tickets" to this repo's
OpenSpec pipeline (`openspec/changes/`, `.omp/skills/openspec-*`).
- Reference wayfinder ticket `#187` and map `#182` as external provenance only, in
the note.
===============================================================================

Task: 2

This phase records the single clause that is in force now, independent of the
fence: the manifest authorability constraint. No installer or governed effect is
built.

Steps:
- Add a requirement to `openspec/specs/lyra-package/spec.md` (or a new OpenSpec
change proposal under `openspec/changes/` first, if the OpenSpec workflow
requires it).
- State in the requirement that any package manifest format must be
machine-authorable, machine-checkable, and renderable for owner review.
- State in the requirement that no field in the manifest format may assume a
human author.
- Keep the requirement scoped to the manifest format only; do not describe
install, versioning, or rollback mechanics.
- Add a non-normative design note stating that the future package-submission
effect should reuse the artifact lifecycle in
`crates/openspine-kernel/src/api/artifact_propose.rs` and the `Lifecycle` state
machine in `crates/openspine-schemas/src/artifact.rs`.
- Record in the note that attenuation-only minting must come from the existing
caveat-chain machinery in `crates/openspine-schemas/src/grant_chain.rs` and
`crates/openspine-authority/src/worker_grant.rs`, so a submitted package can
never carry more authority than the submitter's grant.
- Mark this design note as deferred and gated by the fit review.
===============================================================================

Task: 3

This phase documents the exact routing path for follow-up agents to use once the
human marks the fit review as build-on. No build actions occur in this phase.

Steps:
- Document that when the fit review lands on build-on, the human must remove
`ready-for-human`, remove the `Blocked by:` note, and set `ready-for-agent`.
- Document that the work then routes through the OpenSpec pipeline: draft an
OpenSpec change proposal, apply it, then split it into tickets. This is the
repo-native mapping of "grill → to-spec → to-tickets."
- Document the acceptance constraint that the manifest requirement recorded in
Task 2.1 already binds any future package-submission design.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!