Commit Graph

3 Commits

Author SHA1 Message Date
vasilito b8aac3c9bc D7: editor multi-cursor support
Add secondary_cursors field to Editor with insert_char_multi,
delete_back_multi, delete_forward_multi methods. Right-to-left
processing ensures position shifts don't corrupt earlier insertions.

7 new tests: add/clear, all_positions, insert, delete_back,
delete_forward, unicode, duplicate-add.
2026-07-05 22:29:19 +03:00
vasilito b66a9e509e policy: mark bootloader fork as PENDING_REBASE
The local bootloader fork claims to be upstream 1.0.0 + Red Bear
patches, but the patches in local/patches/bootloader/ do NOT
apply cleanly to upstream 1.0.0. The fork was originally a 0.1.0
baseline with substantial additions that pre-date the upstream-1.0.0
refactor.

Changes:

  * local/fork-upstream-map.toml: set bootloader's upstream tag to
    PENDING_REBASE. The verifier recognises this as a deliberate
    state marker (a fork whose rebase is in progress) and refuses
    the build with a clear error pointing the user to the rebase
    procedure documented in the map.

  * local/scripts/verify-fork-versions.sh: when a fork is marked
    PENDING_REBASE in the map, the script reports a dedicated error
    message instead of running the upstream content comparison (which
    would always fail for a fork in this state).

The current state of the build is:
  * 5 of 6 `-rb1` Cat 2 forks pass the no-fake-version-label
    check (redoxfs, redox-scheme, kernel, installer, userutils).
  * bootloader refuses to build until a real rebase onto a chosen
    upstream tag is completed (the patches must apply cleanly with
    --fuzz=0).
  * installer has additional divergent content that may need a
    rebase too (separate operational task).

This is the strict enforcement the user asked for. The build
cannot proceed silently with fake labels. The user must drive
the rebase work for bootloader (and installer) following the
procedure in fork-upstream-map.toml.
2026-07-05 05:15:27 +03:00
vasilito f7c3d504dd policy: enforce no-fake-version-label rule for Cat 2 forks
Per local/AGENTS.md \xC2\xA7 'No-fake-version-label rule':

  Every Cat 2 fork version MUST match the source content from the
  corresponding upstream release + documented Red Bear patches.
  A `-rbN` label on stale content is a fake label and a policy
  violation.

Changes:

  * local/AGENTS.md: documented the no-fake-version-label rule,
    including what counts as a fake label, the enforcement contract,
    and what a real Red Bear fork looks like.

  * local/fork-upstream-map.toml: authoritative mapping of each
    Cat 2 fork (syscall, libredox, redoxfs, redox-scheme, relibc,
    kernel, bootloader, installer, userutils) to its upstream Git
    URL and release tag.

  * local/scripts/refresh-fork-upstream-map.sh: auto-update the
    fork-upstream-map by querying each upstream repo for the
    current latest stable release tag.

  * local/scripts/verify-fork-versions.sh: preflight enforcement
    script. For each Cat 2 fork with a `-rbN` version field:
      1. Compare fork's file list and content against the upstream
         release tag from the map. Reject the build if files are
         missing (would be a fake label).
      2. Reject the build if files exist in local that don't exist
         in upstream (must be moved to local/patches/<fork>/ as
         documented Red Bear patches).
      3. Reject the build if shared files diverge in content.

  * local/scripts/apply-rb-suffix.sh: invokes
    verify-fork-versions.sh after applying the `-rbN` label so the
    build fails fast if the labelled content is fake.

  * local/scripts/build-preflight.sh: invokes
    verify-fork-versions.sh at the start of every build. Bypassed
    only with REDBEAR_SKIP_FORK_VERIFY=1 (emergency only).

  * local/patches/bottom/0001-ratui-0.30-braille-compat.patch: the
    ratatui 0.30+ compatibility shim for bottom 0.11.2.

This is the structural enforcement that prevents fake labels from
ever reaching the build again. The current 6 forks with `-rbN`
labels are flagged by the verifier — they must be rebased onto
their actual upstream release before the build can succeed.
2026-07-05 02:37:54 +03:00