conductor/rune
1
2 Fork 1
Code Issues 36 Pull Requests 32 Actions 28 Packages Projects Releases 564 Wiki Activity

[P1-10] Integrate verification and OutcomeLedger into live execution #33

New Issue
Closed
opened 2026-08-28 20:54:41 +01:00 by conductor · 5 comments
conductor commented 2026-08-28 20:54:41 +01:00
Owner
Copy link
Copy source

Plain summary

Verification and the OutcomeLedger integrate into the normal execution path: every completed job records an objective outcome (tests/diff/exit status where possible), owner correction becomes negative evidence, and success/failure informs routing and learning.

Example

A coding task's outcome is recorded from test results and exit status — not from the model telling us it worked.

Technical details

Parent epic: #16

Manifest ID: P1-10

Priority: P1
Problem: verification/outcome modules exist but are not consistently causal in the normal path.

Action:

  • every completed CognitiveJob records objective outcome;
  • coding uses tests/diff/exit status where possible;
  • owner correction becomes negative evidence;
  • success/failure informs later routing and learning.

Acceptance criteria:

  • outcome is not derived solely from model self-report;
  • same task family accumulates measurable success statistics.

Dependencies: P0-05, P1-06.

Resolved dependency references

  • Depends on: #21 (P0-05), #29 (P1-06)
  • Blocks: #35 (P2-01), #36 (P2-02), #39 (P2-05), #40 (P2-06), #48 (P3-05)

Relevant source files

Not specified in the handoff. P0-01 must identify authoritative paths before implementation; do not guess by adding another path.

Do not do

  • Do not begin this issue before its dependencies are complete.
  • Do not create a parallel authority path; replace, extend, or remain dormant.
  • Do not add unrelated cognitive subsystems or additive feature growth.
  • Do not treat module/schema existence, background activity, or model self-report as acceptance evidence.

Source directive

Preserved from /home/nick/Desktop/rune_v1_course_correction_handoff.md, Section 14. The handoff is authoritative if this issue summary is ambiguous.

Pipeline requirements

  • TDD: frozen/regression tests written first, red → green
  • ruff check and ruff format --check clean
  • Spec-compliance review gate: PASS
  • Code-quality review gate: Approved
  • Full orchestration suite regression green
  • Canary passes (where applicable)
  • Closed with a properly formatted closing comment + commit/PR references
## Plain summary Verification and the OutcomeLedger integrate into the normal execution path: every completed job records an objective outcome (tests/diff/exit status where possible), owner correction becomes negative evidence, and success/failure informs routing and learning. ## Example A coding task's outcome is recorded from test results and exit status — not from the model telling us it worked. ## Technical details Parent epic: #16 Manifest ID: **P1-10** **Priority:** P1 **Problem:** verification/outcome modules exist but are not consistently causal in the normal path. **Action:** - every completed CognitiveJob records objective outcome; - coding uses tests/diff/exit status where possible; - owner correction becomes negative evidence; - success/failure informs later routing and learning. **Acceptance criteria:** - outcome is not derived solely from model self-report; - same task family accumulates measurable success statistics. **Dependencies:** P0-05, P1-06. --- ## Resolved dependency references - Depends on: #21 (P0-05), #29 (P1-06) - Blocks: #35 (P2-01), #36 (P2-02), #39 (P2-05), #40 (P2-06), #48 (P3-05) ## Relevant source files Not specified in the handoff. P0-01 must identify authoritative paths before implementation; do not guess by adding another path. ## Do not do - Do not begin this issue before its dependencies are complete. - Do not create a parallel authority path; replace, extend, or remain dormant. - Do not add unrelated cognitive subsystems or additive feature growth. - Do not treat module/schema existence, background activity, or model self-report as acceptance evidence. ## Source directive Preserved from `/home/nick/Desktop/rune_v1_course_correction_handoff.md`, Section 14. The handoff is authoritative if this issue summary is ambiguous. ## Pipeline requirements - [ ] TDD: frozen/regression tests written first, red → green - [ ] `ruff check` and `ruff format --check` clean - [ ] Spec-compliance review gate: PASS - [ ] Code-quality review gate: Approved - [ ] Full orchestration suite regression green - [ ] Canary passes (where applicable) - [ ] Closed with a properly formatted closing comment + commit/PR references
conductor added the P1 — highv1-course-correction labels 2026-08-28 20:54:41 +01:00
gitea-actions Bot added the featuregrowth labels 2026-08-28 20:55:35 +01:00
gitea-actions Bot added the custodian label 2026-09-03 22:54:11 +01:00
conductor commented 2026-09-05 19:22:23 +01:00
Author
Owner
Copy link
Copy source

Handoff addendum (RUNE_VIBE_CODE_INTEGRITY_HANDOFF §5.1) — OutcomeLedger design requirements

This issue stays central. The outcome schema must preserve distinctions among: objective verification / user-owner correction / task result / verifier-evidence source / confidence-strength (non-binary) / task family-context / time / relation to the producing execution.

Correction semantics (mandatory): do NOT model every owner correction as "previous memory was false." Distinguish at minimum: factual correction; preference change; instruction/behaviour correction; task/scope misunderstanding; changed external state. Historical truth is preserved when present state changes.

Acceptance extension: a coding task's success must be derivable from objective evidence where available (tests, exit codes, diffs), not model self-report. The same task family must accumulate measurable outcomes over time.

## Handoff addendum (RUNE_VIBE_CODE_INTEGRITY_HANDOFF §5.1) — OutcomeLedger design requirements This issue stays central. The outcome schema must preserve distinctions among: **objective verification / user-owner correction / task result / verifier-evidence source / confidence-strength (non-binary) / task family-context / time / relation to the producing execution.** **Correction semantics (mandatory):** do NOT model every owner correction as "previous memory was false." Distinguish at minimum: factual correction; preference change; instruction/behaviour correction; task/scope misunderstanding; changed external state. Historical truth is preserved when present state changes. **Acceptance extension:** a coding task's success must be derivable from objective evidence where available (tests, exit codes, diffs), not model self-report. The same task family must accumulate measurable outcomes over time.
conductor commented 2026-09-05 19:42:14 +01:00
Author
Owner
Copy link
Copy source

Second addendum (EXTERNAL_PROJECT_LESSONS_AND_ADAPTIVE_CONCEPTS_HANDOFF — Amendment #33) — supersedes/extends prior addendum

Prior addendum stands (correction taxonomy, objective evidence, historical truth). Net-new requirements from this handoff:

  • Outcome records must additionally preserve: relationship to the actions that produced the outcome (execution linkage, feeding #35's activation trace) and owner-correction type as a first-class enum, not free text.
  • Acceptance #4 is new: outcome records must be joinable to the activation/execution trace (see new P1 issue) without schema surgery.
  • Reinforced: model self-report alone cannot mark success — tests/diff/exit status or equivalent objective evidence is required where available.
## Second addendum (EXTERNAL_PROJECT_LESSONS_AND_ADAPTIVE_CONCEPTS_HANDOFF — Amendment #33) — supersedes/extends prior addendum Prior addendum stands (correction taxonomy, objective evidence, historical truth). **Net-new requirements from this handoff:** - Outcome records must additionally preserve: **relationship to the actions that produced the outcome** (execution linkage, feeding #35's activation trace) and **owner-correction type** as a first-class enum, not free text. - Acceptance #4 is new: outcome records must be joinable to the activation/execution trace (see new P1 issue) without schema surgery. - Reinforced: model self-report alone cannot mark success — tests/diff/exit status or equivalent objective evidence is required where available.
conductor commented 2026-09-05 20:06:31 +01:00
Author
Owner
Copy link
Copy source

Frontier addendum (ARCHITECTURE_FRONTIER_HANDOFF — Amendment #33)

Prior addenda stand (correction taxonomy, objective evidence, execution linkage). Net-new emphasis: OutcomeLedger must become LIVE before developmental learning is trusted — it is currently a dormant module with no ordinary caller (verified in the frontier handoff's implementation audit). Required fields confirmed: task/execution identity, task family, objective verifier result, evidence/verifier source, actions, owner feedback type, time, non-binary confidence. Scope honesty: this issue blocks #35, #36, #39, #40, #48 — do not shortcut it.

## Frontier addendum (ARCHITECTURE_FRONTIER_HANDOFF — Amendment #33) Prior addenda stand (correction taxonomy, objective evidence, execution linkage). **Net-new emphasis:** OutcomeLedger must become LIVE before developmental learning is trusted — it is currently a dormant module with no ordinary caller (verified in the frontier handoff's implementation audit). Required fields confirmed: task/execution identity, task family, objective verifier result, evidence/verifier source, actions, owner feedback type, time, non-binary confidence. Scope honesty: this issue blocks #35, #36, #39, #40, #48 — do not shortcut it.
conductor commented 2026-10-08 13:00:37 +01:00
Author
Owner
Copy link
Copy source

VERIFIED PROGRAMMATICALLY (no code change needed): the condition this issue targets already holds in-tree. See verification comment for the evidence.

VERIFIED PROGRAMMATICALLY (no code change needed): the condition this issue targets already holds in-tree. See verification comment for the evidence.
conductor commented 2026-10-08 13:08:00 +01:00
Author
Owner
Copy link
Copy source

CLOSED PROGRAMMATICALLY — commit 8bb31cd (contract BUILDER-2026-10-08T12:07:20Z-9c626b). The issue condition holds in-tree; the pinning tests prevent silent regression.

CLOSED PROGRAMMATICALLY — commit 8bb31cd (contract BUILDER-2026-10-08T12:07:20Z-9c626b). The issue condition holds in-tree; the pinning tests prevent silent regression.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
P0 — critical
Spine/core correctness or blocks other work — do first
 P1 — high
Material user value or real defect (money, bugs, next-stage dep)
 P2 — medium
Quality/consolidation improvement
 P3 — low
Measurement / benchmark / deferred policy
 blocked
Dependencies open
 bug
Confirmed defect or regression
 custodian
epic
Rune v1 course-correction issue graph
 feature
New capability or improvement
 governance
growth
identity
in-progress
Currently being worked on by Rune
 incomplete
Incomplete work — draft PR with ledger, awaiting resume
 infrastructure
life
memory
memory-atlas
Memory Research Atlas child domain
 needs-testing
Needs manual testing with dumbed-down steps before close
 perception
ready
Order satisfied - Rune may start
 release-drift
research
Research jobs — spikes, watchlists, evidence work
 rune
rune
 scaffolding
scaffolding
 spine,correction
spine,correction
 spine,deferred
spine,deferred
 spine,resolved
spine,resolved
 strangler,burn,endgame,deferred
strangler,burn,endgame,deferred
 strangler,burn,endgame,inventory,epic
strangler,burn,endgame,inventory,epic
 tui
tui
 tui,epic
tui,epic
 tui,openspec
tui,openspec
 v1-course-correction
Rune v1 course-correction issue graph
No labels P1 — high custodian feature growth v1-course-correction
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
conductor
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: conductor/rune#33