Upstream: do not report intentional ACP SIGTERM as a harness failure

[100yenadmin]

Parent: #36

Problem

The native managed-agent process monitor records every non-success child status as a harness error. During an intentional stop, reconfiguration, application shutdown, or welcome-team lifecycle transition, the child can exit on SIGTERM before the stop path clears the status.

The installed canary showed a red harness exited with status signal: 15 (SIGTERM) error with no harness output. That message does not distinguish an expected lifecycle stop from a crash or provider/runtime failure.

Outcome

Expected ACP process termination is represented as stopped/restarting, while unexpected termination remains an actionable error with useful evidence.

Acceptance

• The process supervisor records stop intent before sending SIGTERM.
• An exit matching active stop/reconfigure/app-shutdown intent does not set last_error.
• Unexpected SIGTERM, other signals, and nonzero exits remain errors.
• Restart/reconfiguration state is explicit and cannot remain indefinitely pending.
• Empty logs do not imply provider authentication or model failure.
• Welcome onboarding receives a terminal success/failure result instead of swallowing the process failure behind an indefinite banner.
• Race-focused process-monitor tests cover stop-before-monitor, monitor-before-clear, rapid reconfigure, app shutdown, and genuine unexpected termination.
• Canonical CI and one focused lifecycle review pass on the exact head.

Scope

This is a generic native agent lifecycle correction and should remain upstream-ready. It must not introduce Electric OAuth, Supabase, company VM, or Hive branding dependencies.

Proof boundary

Tests prove classification logic. Installed proof must show a normal stop/reconfigure without a red error and a deliberately failed harness with a truthful actionable error.

[100yenadmin]

Release disposition

Accepted follow-up for the Guarded Business Beta and a separate upstream-ready
change.

#44 removes the current managed product path that auto-launches local welcome
agents, so expected local SIGTERM classification no longer blocks the managed
Internal Canary. Native unmanaged Buzz still deserves the generic lifecycle
correction, but it must remain a separate fresh-upstream change with its own
focused race tests, CI, and semantic review.

[100yenadmin]

Tracker classification: generic upstream candidate, separate from Hive release work.

This issue belongs to the Upstream Contributions milestone and is not a blocker for the Hive internal canary. Implementation must start from a fresh current upstream base and contain no Electric OAuth, branding, endpoints, Supabase, company catalog, or VM policy.

[100yenadmin]

2026-07-30 upstream recheck: no merged block/buzz change was found that classifies intentional managed-agent SIGTERM separately from failure on current main 63496cc1d4c6f1b7c613801bdcc694169dcf391a. Keep this generic post-canary candidate. It must not grow into a Hive-specific process supervisor or block the v0.5.2 reset unless the exact installed path reproduces the misleading error.

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #42 - Upstream: do not report intentional ACP SIGTERM as a harness failure
State: open; milestone: Hive — Upstream Contributions (post-canary)

Related issues/PRs: #36.
Existing labels: bug, upstream-candidate.
Suggested labels: security, tests.
Suggested owners: none.

Related context

• Reset Hive to upstream-first parity with thin Electric auth and Hermes adapters #36 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: Upstream: do not report intentional ACP SIGTERM as a harness failure - Parent: #36 ## Problem The native managed-agent process monitor records every non-success child status as a harness error. During an intentional stop, reconfiguration, application shutdown, or welcome-team lifecycle
Product fit: Product/UX-sensitive issue; review against repo vision and user flow quality, not only technical P0/P1 risk.
Implementation wedge: Ship the smallest user-visible path or prototype that can be smoke-tested against the intended experience.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.
• Current market/product examples, capped and cited, only when they change implementation direction.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• UX/product smoke or screenshot proof when implementation changes user flow.
• Contract or degraded-mode proof before runtime promotion.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.
• Technical severity alone can miss product/UX regressions; include product-manager review framing.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [enabled] current_market_examples: Use for product/UX/market positioning issues with freshness dates.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.