erix/integration
Watch
1
0
Fork
You've already forked integration
 0
generated from erix/meta
Code Issues 63 Pull requests 1 Projects Releases 10 Packages Wiki Activity Actions 24

[FEATURE] Close carried startup and predecessor validation gates #6

New issue
Open
opened 2026-09-12 07:56:24 +02:00 by erikinkinen · 0 comments
erikinkinen commented 2026-09-12 07:56:24 +02:00
Owner
Copy link

Problem and motivation

Phase 6 must start from an accountable source graph and preserve unfinished startup acceptance. A predecessor CI result or faster generated code cannot establish the new branch’s runtime performance.

Proposed behavior and scope

Retain the carried source and validation evidence, establish its disposition in the signed feature ancestry, audit current exact-head CI, and compare matching private images under the existing startup oracle. Close the carried gates only with complete adjacent control/candidate observations.

This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is Phase 6 and AC1–AC24.

Authority, security and reliability

Keep canonical images intact while private copies are tested. Preserve exact source/image identity, owned worker and observer cleanup, required service/caret markers, and the 120-second hard, 15-second silence and 10-second command collection limits. Security and reliability checks take precedence over speed.

Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel.

Acceptance criteria

  • Preserve the archived tracker and an evidence index for the exact source graphs, CI
    logs, main-image hashes, rejected experiments and all failed timing observations; distinguish
    historical results from current-head gates.
  • Audit the carried predecessor CI to terminal status, including every job/log and
    complete scenario/post-image count; classify remaining failures without weakening markers,
    source identity, worker ownership or deadlines.
  • Review the carried signed checkpoint and record its disposition: preserve its
    ancestry when creating feature/posix-compat, and publish a coherent new-branch graph only
    after predecessor evidence is retained. Record complete commit hashes; do not drop a committed
    pin or silently substitute an older graph.
  • Run the carried checkpoint’s own exact-head full CI and a fresh repository-wide CI
    inventory; resolve failures and warnings at their owners. Preserve previously observed
    failures until their exact corrected revisions have passing evidence.
  • Revalidate the prepared direct-chunk private-image recipe against the chosen Phase
    6 base before reuse; bind all source revisions, environments, cache keys, executable PT_LOAD
    bytes and rootd path/capacity differences.
  • Build/audit matching private dev/release images once admitted; retain original
    helper failures and the narrow proven locale-receipt handling. Do not reuse a predecessor's
    symbol addresses or compiled-object attribution.
  • Collect one adjacent audited control and two complete candidate startup
    observations, with no concurrent local VM/compiler, using unchanged 120 s total / 15 s silence
    / 10 s command collection limits.
  • Close the carried startup acceptance only after both candidate observations
    satisfy root-to-final-READY ≤5 s, largest service-ready gap ≤1 s,
    final-READY-to-full-editor-caret ≤1 s, and the exact four-command interval ≤2 s. Preserve the
    maintained oracle and command; never retry unchanged input to green.
  • Record remaining bottlenecks as integration#3 findings if integration#6 fails; validate each
    eventual fix with strict component checks and matching VMs.
  • Update the carried acceptance report and component/manual status with actual
    results; retain all six old unchecked rows as covered by these items rather than counting
    duplicate validation prose as six independent gates.

For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates.

Alternatives and tradeoffs

Treating an earlier green CI or host code-generation improvement as startup acceptance would leave runtime behavior unverified. New diagnostics may explain failed observations, but must retain the original failure and unchanged timing endpoints.

Tracking and rollout

Dependencies: meta#2, integration#3

Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use feature/posix-compat, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection.

Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.

## Problem and motivation Phase 6 must start from an accountable source graph and preserve unfinished startup acceptance. A predecessor CI result or faster generated code cannot establish the new branch’s runtime performance. ## Proposed behavior and scope Retain the carried source and validation evidence, establish its disposition in the signed feature ancestry, audit current exact-head CI, and compare matching private images under the existing startup oracle. Close the carried gates only with complete adjacent control/candidate observations. This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is [Phase 6 and AC1–AC24](https://git.erikinkinen.fi/erix/docs/src/branch/main/phases/6.md). ## Authority, security and reliability Keep canonical images intact while private copies are tested. Preserve exact source/image identity, owned worker and observer cleanup, required service/caret markers, and the 120-second hard, 15-second silence and 10-second command collection limits. Security and reliability checks take precedence over speed. Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel. ## Acceptance criteria - [ ] Preserve the archived tracker and an evidence index for the exact source graphs, CI logs, main-image hashes, rejected experiments and all failed timing observations; distinguish historical results from current-head gates. - [ ] Audit the carried predecessor CI to terminal status, including every job/log and complete scenario/post-image count; classify remaining failures without weakening markers, source identity, worker ownership or deadlines. - [ ] Review the carried signed checkpoint and record its disposition: preserve its ancestry when creating feature/posix-compat, and publish a coherent new-branch graph only after predecessor evidence is retained. Record complete commit hashes; do not drop a committed pin or silently substitute an older graph. - [ ] Run the carried checkpoint’s own exact-head full CI and a fresh repository-wide CI inventory; resolve failures and warnings at their owners. Preserve previously observed failures until their exact corrected revisions have passing evidence. - [ ] Revalidate the prepared direct-chunk private-image recipe against the chosen Phase 6 base before reuse; bind all source revisions, environments, cache keys, executable PT_LOAD bytes and rootd path/capacity differences. - [ ] Build/audit matching private dev/release images once admitted; retain original helper failures and the narrow proven locale-receipt handling. Do not reuse a predecessor's symbol addresses or compiled-object attribution. - [ ] Collect one adjacent audited control and two complete candidate startup observations, with no concurrent local VM/compiler, using unchanged 120 s total / 15 s silence / 10 s command collection limits. - [ ] Close the carried startup acceptance only after **both** candidate observations satisfy root-to-final-READY ≤5 s, largest service-ready gap ≤1 s, final-READY-to-full-editor-caret ≤1 s, and the exact four-command interval ≤2 s. Preserve the maintained oracle and command; never retry unchanged input to green. - [ ] Record remaining bottlenecks as [integration#3](https://git.erikinkinen.fi/erix/integration/issues/3) findings if [integration#6](https://git.erikinkinen.fi/erix/integration/issues/6) fails; validate each eventual fix with strict component checks and matching VMs. - [ ] Update the carried acceptance report and component/manual status with actual results; retain all six old unchecked rows as covered by these items rather than counting duplicate validation prose as six independent gates. For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates. ## Alternatives and tradeoffs Treating an earlier green CI or host code-generation improvement as startup acceptance would leave runtime behavior unverified. New diagnostics may explain failed observations, but must retain the original failure and unchanged timing endpoints. ## Tracking and rollout Dependencies: [meta#2](https://git.erikinkinen.fi/erix/meta/issues/2), [integration#3](https://git.erikinkinen.fi/erix/integration/issues/3) Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use `feature/posix-compat`, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection. Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.
erikinkinen changed title from [FEATURE] [P00] Close carried startup and predecessor validation gates to [FEATURE] Close carried startup and predecessor validation gates 2026-09-12 08:02:03 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/posix-compat
feature/native-cli
feature/phase-4-audit
feature/dynlink
feature/program-loader
feature/e2fs-fat
feature/block-devices
feature/vfs
feature/centralized-process-authority
ci-feature-posix-compat
nightly
ci-feature-native-cli
ci-feature-phase-4-audit
ci-feature-dynlink
ci-feature-program-loader
ci-feature-e2fs-fat
ci-feature-block-devices
ci-feature-vfs
ci-feature-centralized-process-authority
Labels
Clear labels
  
bug
Something is not working

  
ci

   
docs

   
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
help wanted
Need some help

  
invalid
Something is wrong

  
performance
Measured performance profiling, bottleneck analysis, and regression budgets.

  
phase-6
Phase 6: POSIX compatibility, full EriX self-hosting, and its required audits and validation.

  
question
More information is needed

  
refactor
Code cleanup, removal of obsolete paths, and structural improvements preserving behavior.

  
security

   
wontfix
This won't be fixed

No labels
bug
ci
docs
duplicate
enhancement
help wanted
invalid
performance
phase-6
question
refactor
security
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
erix/integration#6
No description provided.