erix/meta
Template
Watch
1
0
Fork
You've already forked meta
 0
Code Issues 2 Pull requests 1 Projects Releases Packages Wiki Activity Actions

[FEATURE] Coordinate Phase 6 through issues and WIP pull requests #2

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

Problem and motivation

Cross-repository implementation needs public ownership, dependency links and evidence-backed status before work starts. Duplicate issues or prematurely ready PRs obscure the complete phase goal.

Proposed behavior and scope

Coordinate Phase 6 through issues, phase/topic labels, dependency links and WIP pull requests in the owning repositories. Use the existing authorized Forgejo account and the supported REST API. Create new repositories from meta before specializing them and keep public issue/PR state consistent with the actual deliverables.

The normative basis is Phase 6 and AC1–AC24. Planning publication is separate from implementation and two-generation self-hosting acceptance.

Authority, security and reliability

Use only the authorized identity and required organization/repository permissions. Keep credentials, signing material, private evidence and suspected vulnerability details out of public records. Preserve human edits and never fabricate review, signing or release approval. Apply the priority order: security, reliability, then performance.

Acceptance criteria

  • Verify the deployed Forgejo version, authenticated identity and required organization/repository API permissions without widening privileges or exposing credentials.
  • Create the work-stream and bounded implementation/audit issues in their owning repositories, with clear scope, dependencies, acceptance criteria and authority rationale.
  • Keep an idempotent issue/PR index; detect existing records before creation and preserve intervening human edits.
  • Create a feature/posix-compat PR in every altered repository after its first reviewable signed checkpoint, retaining the exact "WIP: " title prefix until its declared scope and required dependent validation pass.
  • Keep PR descriptions current with implemented and remaining scope, security decisions, exact revisions, tests, failures and pending CI.
  • Make public updates through the authorized identity without claiming personal review or approval that has not occurred.
  • Keep secrets and vulnerability-sensitive details out of issues, PRs and artifacts; use the restricted SECURITY.md reporting channel when needed.
  • Create each required new repository from meta, verify inherited shared files, clone and branch before specialization, then add its audit, CI, documentation, manual and source-catalog coverage before consumers depend on it.
  • Close issues and remove "WIP: " only after their complete acceptance evidence exists; readiness does not authorize merging or releasing.
  • Reconcile altered repositories, issues, PRs, exact component graphs and CI evidence at every checkpoint and final handoff.

Alternatives and tradeoffs

Use supported API operations and descriptive Forgejo cross-references. Exact source identity and actual validation outcomes determine acceptance; labels and issue closure alone do not establish a working runtime or self-hosting result.

Tracking and rollout

Use feature_request.md for plan, design and audit issues: its six body sections, [FEATURE] prefix and enhancement label. Significant defects and regressions use bug_report.md with its canonical sections, [BUG] prefix, bug label, reproduction, expected/actual behavior, constraints and evidence. Every phase issue and PR receives phase-6 plus applicable security, ci, docs, performance and refactor labels. Public references use descriptive titles and Forgejo issue/PR links.

Use feature/posix-compat, regular signed commits with canonical tagged titles and explanatory bodies, and exact 40-character lowercase commit hashes for cross-repository Cargo dependencies, source catalogs and CI helpers. Keep existing main images unchanged until explicitly authorized promotion. Required formatting, strict Clippy, unit/doctests, warning-denied builds, applicable VM checks and current-revision CI remain mandatory for implementation slices.

## Problem and motivation Cross-repository implementation needs public ownership, dependency links and evidence-backed status before work starts. Duplicate issues or prematurely ready PRs obscure the complete phase goal. ## Proposed behavior and scope Coordinate Phase 6 through issues, phase/topic labels, dependency links and WIP pull requests in the owning repositories. Use the existing authorized Forgejo account and the supported REST API. Create new repositories from meta before specializing them and keep public issue/PR state consistent with the actual deliverables. The normative basis is [Phase 6 and AC1–AC24](https://git.erikinkinen.fi/erix/docs/src/branch/main/phases/6.md). Planning publication is separate from implementation and two-generation self-hosting acceptance. ## Authority, security and reliability Use only the authorized identity and required organization/repository permissions. Keep credentials, signing material, private evidence and suspected vulnerability details out of public records. Preserve human edits and never fabricate review, signing or release approval. Apply the priority order: security, reliability, then performance. ## Acceptance criteria - [ ] Verify the deployed Forgejo version, authenticated identity and required organization/repository API permissions without widening privileges or exposing credentials. - [ ] Create the work-stream and bounded implementation/audit issues in their owning repositories, with clear scope, dependencies, acceptance criteria and authority rationale. - [ ] Keep an idempotent issue/PR index; detect existing records before creation and preserve intervening human edits. - [ ] Create a feature/posix-compat PR in every altered repository after its first reviewable signed checkpoint, retaining the exact "WIP: " title prefix until its declared scope and required dependent validation pass. - [ ] Keep PR descriptions current with implemented and remaining scope, security decisions, exact revisions, tests, failures and pending CI. - [ ] Make public updates through the authorized identity without claiming personal review or approval that has not occurred. - [ ] Keep secrets and vulnerability-sensitive details out of issues, PRs and artifacts; use the restricted SECURITY.md reporting channel when needed. - [ ] Create each required new repository from meta, verify inherited shared files, clone and branch before specialization, then add its audit, CI, documentation, manual and source-catalog coverage before consumers depend on it. - [ ] Close issues and remove "WIP: " only after their complete acceptance evidence exists; readiness does not authorize merging or releasing. - [ ] Reconcile altered repositories, issues, PRs, exact component graphs and CI evidence at every checkpoint and final handoff. ## Alternatives and tradeoffs Use supported API operations and descriptive Forgejo cross-references. Exact source identity and actual validation outcomes determine acceptance; labels and issue closure alone do not establish a working runtime or self-hosting result. ## Tracking and rollout Use feature_request.md for plan, design and audit issues: its six body sections, [FEATURE] prefix and enhancement label. Significant defects and regressions use bug_report.md with its canonical sections, [BUG] prefix, bug label, reproduction, expected/actual behavior, constraints and evidence. Every phase issue and PR receives phase-6 plus applicable security, ci, docs, performance and refactor labels. Public references use descriptive titles and Forgejo issue/PR links. Use feature/posix-compat, regular signed commits with canonical tagged titles and explanatory bodies, and exact 40-character lowercase commit hashes for cross-repository Cargo dependencies, source catalogs and CI helpers. Keep existing main images unchanged until explicitly authorized promotion. Required formatting, strict Clippy, unit/doctests, warning-denied builds, applicable VM checks and current-revision CI remain mandatory for implementation slices.
erikinkinen changed title from [FEATURE] [P18] Coordinate Phase 6 through public issues, WIP PRs and one organization project to [FEATURE] Coordinate Phase 6 through public issues, WIP PRs and one organization project 2026-09-12 08:01:58 +02:00
erikinkinen changed title from [FEATURE] Coordinate Phase 6 through public issues, WIP PRs and one organization project to [FEATURE] Coordinate Phase 6 through issues and WIP pull requests 2026-09-12 08:17:43 +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/e2fs-fat
No results found.
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/meta#2
No description provided.