feat(release): observe owned Core artifact lifecycle

Closed
  • Is something wrong?
#2,100 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@dnlrsls is already working on this.

Since Oct 24, 2026.

  • #2101 by @dnlrsls — open

Assessment

This issue has not been assessed yet.

Description

status:approved type:feature
Existing Issue Search
  • I searched existing issues and will add evidence to a canonical tracker when applicable.

Parent: #2055. This is the separately deliverable Core lifecycle slice following merged admission PR #2067 / closed #2066. Targeted issue and open-PR searches found no separate Core artifact lifecycle delivery tracker; related staging and runtime work does not replace this slice.

🔍 Observed Consequence

Artifact admission can bind reviewed inputs, but cannot show that the selected production Core binary started, authenticated and shut down under owned isolation. Reviewers cannot distinguish verified child termination from an operational process error.

💡 Desired Outcome

An operator can inspect a non-approving lifecycle observation for the exact admitted Core binary, with authenticated instance identity, observed runtime version and explicit exit/join/cleanup outcomes. Unknown termination must retain owned state rather than claim success.

📦 Affected Area

CLI (commands, flags)

Release Context

Development main 171bfda37ecea77724b93681fb6c015f869b55eb. Original independently reviewed lifecycle candidate ec47b5421b2fcd504b2a6c41ae56bdbdf9c8d1ee; current port f0e89646. No public release selected.

🔄 Workarounds and Constraints

Keep #2055 open. This slice does not import Pi, execute representative Pi workflows, establish genuine installed-Pi/SDK behavior, authorize publication or grant release eligibility. No downloads, SDK/executable override, transport redesign, new staging dispatch or publisher/coordinator. Disposable copies and environment containment are not a hostile-code sandbox.

📎 Additional Context
Maintainer-approved design and scope

The maintainer explicitly authorized this child, approval, assignment to dnlrsls and the second Core-only PR, retaining the existing 481-line slice and its 500-line bounded exception.

  • Execute only explicitly admitted/measured Core bytes using serve --session-owned, owned stdin and private random 256-bit token.
  • Use owned outside-Git runtime cwd/data/home/config/temp and a minimal environment; do not forward credentials/cloud/transport settings.
  • Verify bounded loopback readiness, direct owned PID, private-token authentication and the same instance identity.
  • Require observed child exit for joined cleanup. A ChildProcess error is not termination; unknown cleanup retains state. Readiness/EOF/kill-join bounds remain 5s/3s/2s.
  • Record raw runtime health version separately from source/version intent and build metadata; recheck originals.
  • Keep outcome blocked/exit2 and Pi workflows unavailable; preserve legacy modes and align help/docs.
Evidence and independent review

Historical ec47 evidence, not new post-port runs: affected package PASS201.079s with mandatory real TypeBox; scoped lint zero issues; meaningful failed-kill regression RED then GREEN; independent targeted fault test PASS9.830s and ownership review with no remaining blockers. The defect's root cause was treating a ChildProcess operational error as proof of exit, permitting false joined/cleanup and unsafe removal; the fix waits for actual exit after a known spawn.
A prior selected production Core smoke observed authenticated health3.5.2 and EOF/exit0, but preceded that fault correction and is NOT post-correction production evidence. Pi was never imported.
Original timeout/preparation failures remain historical failures, not retroactive passes. Native assessment was unavailable in the old private inventory; no native approval claimed.
Current-port byte/scope checks and independent review are being collected; hosted full unit/E2E/plugin/platform CI remains pending until the PR exists and runs. No new production execution is requested. Changes are limited to the eight ec47 paths: release-candidate Core helper/tests, input/CLI integration, legacy assertions and docs.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
10h 51m
Merged PRs (30d)
277

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.