rk 0.1.14

• Say how long each step took. On a terminal, a finished step keeps its
  time once it reaches a second (✓ package archive staged · 1m 41s), and
  a successful stage or release of ten seconds or more ends with one
  line of phases: Done in 2m 53s · preparing 2s · checking stages 31s · staging 1m 58s · publishing 22s. Time at rk's confirmation prompt is not
  counted. Pipes and --json are unchanged.

  • --timings prints the whole breakdown after the run, to stderr: every
    phase and step, however fast, for a run that stopped too. It also writes
    the run to .rk/timings.json as a trace that Perfetto opens.

• Show what rk is doing while it checks saved stages, and check them
  faster. Between the last Releasing (or Staging) heading and the
  preparation order, rk verifies every unit's saved stage. It printed nothing
  there, often for tens of seconds. A Checking stages board now shows each
  unit's saved stage being verified, the units' public targets being read,
  and, for a unit with no stage, its dependencies being resolved. A row is
  active only while its own work runs, so a refusal marks the work that
  failed and nothing else, and the board is printed before the refusal.

  • Reusing four saved stages took about half as long in a measured
    four-package release. rk no longer runs the same work again within one
    run: probing a Dart SDK behind a launcher such as Flutter's dart,
    reading a file from a commit with its own git show, and re-hashing
    every staged file each time a stage is opened. Authorization still asks
    a Dart launcher which SDK it runs, before and after the yes, so a version
    manager that switches SDKs mid-run is noticed before anything is
    published.
  • Fresh staging preloads a unit's dependency archives in one
    dart pub cache preload per registry, instead of one per archive, with
    the same two minutes per archive. If Pub refuses the batch, each archive
    is retried alone, so an error still names the archive; when each one
    preloads alone, staging goes on.

• rk depends on Fleury 0.1 from pub.dev. The repository's override to a
  Fleury revision with the native output, inline shutdown and navigation
  fixes (Fleury #278) is gone: Fleury 0.1.0 includes them.

• Keep a released unit released while its own files are unchanged. A bare
  rk release used to stop at any unit whose tag was not on the current
  commit. It called the unit released from different source and asked for a
  version bump, even when later commits touched only other units or files
  outside every unit.

  • rk now compares the unit's directories between its tag and the current
    commit. Unchanged, the unit counts as released; changed, rk still asks
    for a bump (RK-MONO-004). Files outside the unit's directories, such
    as a root toolchain file or a sibling package, do not count: to release
    a change there, bump the version.
  • When the tagged commit is not in the clone, rk asks you to fetch the
    tag rather than calling it different source.
  • This only decides whether a unit is already released. Once a commit is
    staged, its bytes still need a tag on that commit.
  • A release interrupted after its tag is finished from the tagged commit,
    whose stage the tag binds: rk refuses to finish it from a later one
    (RK-GIT-009) and says how.

• Ask once for a repository release. A bare rk release of several units
  shows what each will publish, marked permanent or first claim, and asks
  one question before any of them acts.

  • Each unit still reads everything again before it acts. It asks for
    itself, and says why, if those reads show something the question did
    not, or if rk warns about it while it stages.
  • If a unit already cannot go ahead, as far as rk can tell before staging,
    each unit asks for itself, as before. --yes reads nothing ahead of the
    units.

• Publish release assets that a project's own build makes. A project declares
  build, the command, and assets, the files that command writes to
  {out}, and rk publishes those files as the unit's GitHub release.

  • The command runs from a clean copy of the committed source, once per
    stage, with the release's facts in RK_OUT, RK_SOURCE_COMMIT,
    RK_REPOSITORY, RK_VERSION and RK_TAG.
  • Only the declared files reach the release, each under its file name. The
    manifest types them asset, whatever their names end in.
  • A Rust crate (a directory with a Cargo.toml and no pubspec.yaml) is
    released this way, named and versioned by its [package] table.
  • The plan and JSON report show the work as a buildAssets step.
  • rk refuses a build that fails or cannot start (RK-BUILD-003) or misses
    a declared asset (RK-BUILD-004), and a unit whose settings do not add
    up (RK-CONF-042 to 045, RK-RES-016, RK-RES-017, RK-PKG-003).
  • On a terminal, the stage shows the build's latest line beside its
    elapsed time. A failed build's remedy ends with its last lines, and a
    missing asset's names what the build wrote instead.
  • RK_CACHE gives the build a directory that outlives the stage, under
    .rk/cache, for what the next build can reuse.

• Replace rk release --stage with rk stage [unit] to prepare and validate
  artifacts without publishing. rk release still prepares as needed and
  publishes. JSON schema 12 identifies the operation through command and
  removes the obsolete mode.stage field.

• Read the pubspec YAML that real packages write and that rk used to refuse.

  • Flow collections ([a, b], {name: value}), after their key or on the
    lines below it, and continued over several lines.
  • Plain and quoted scalars wrapped over several lines or starting below
    their key, folded as YAML folds them.
  • Double-quoted escapes and doubled single quotes, decoded as YAML decodes
    them.
  • Lone carriage returns as line breaks, and a leading document marker.
  • Only spaces and tabs are white space, as in YAML.
  • Every pubspec.yaml and pubspec_overrides.yaml in a 1,594-file local pub
    cache reads exactly as package:yaml reads it. So does every document that
    both parsers accept in 240,000 generated by two differential fuzzers.
  • What rk does not read is refused rather than read as something else:
    • anchors, aliases, tags, complex keys and duplicate keys;
    • key: value pairs in flow sequences;
    • sequences nested on one line;
    • block scalar headers below their key;
    • undefined escapes;
    • unclosed collections and quotes;
    • flow lines not indented past their key;
    • documents that are not maps.

• Refuse a tracked dependency override (RK-PUB-008) only when it reaches the
  staged package, as Pub reports it.

  • The stage resolves its mirror of the source with dart pub get and
    dart pub deps, so Pub decides what is overridden:
    • Pub's compact report lists what it read from every package's
      declarations.
    • pub get, asked for its full report, prints each override it applied.
    • Its lockfile marks overrides.
  • rk adds its own reading of the declarations to these.
  • Pub records a snapshot carries from an earlier resolution are cleared
    first. Examples are not resolved, as pub publish does not resolve them.
  • rk refuses when the package reaches an overridden package, or is one.
  • It also refuses any reached package that Pub took from a path or Git
    source, because consumers receive only hosted and SDK packages.
  • Overrides that reach only other workspace members are listed in the run's
    report as pub-overrides-<package>.txt.

• Refuse to stage a package when rk cannot read Pub's resolution of it
  (RK-PUB-016): a failed resolution, a graph rk does not read, or no record
  of where Pub resolved or what its lockfile says.

• Refuse to stage a package that resolves with Flutter packages when rk's Dart
  is not a Flutter SDK's (RK-PUB-014). The check runs before Pub when rk can
  read the workspace, and from Pub's resolved graph otherwise. The stage
  records the Dart it uses, and a standalone one would depend on an
  unrecorded FLUTTER_ROOT.

• Validate a package against the versions its consumers resolve.

  • Pub resolves a second mirror of the snapshot with the package as a root
    of its own, then validates and archives it there. Other workspace members,
    the workspace root and tracked lockfiles no longer hold its dependencies
    to versions consumers do not get.
  • Workspace packages released in the same unit, and those needed only to
    develop it, come from the snapshot. Everything else comes from pub.dev.
  • The archive is unchanged: Pub never archives the pubspec_overrides.yaml
    rk writes there, or a lockfile.
  • rk refuses a package Pub cannot resolve that way (RK-PUB-017).

• Clear tracked lockfiles before Pub resolves the snapshot.

• Read the graph pub get recorded when dart pub deps --json fails. It
  fails when a workspace member's overrides file leaves out a package its
  pubspec overrides, and rk used to refuse such a workspace (RK-PUB-016).

• Report the warnings Pub finds while writing an archive (RK-PUB-012). With
  warnings alone, Pub exits 0, and rk used to drop them, including analysis
  errors in lib.

• Add an inline version table to rk use. Installed versions remain visible
  while remote checks run independently. Install and Update are separate from
  Use; Update appears only for a confirmed newer version. Navigation and checks
  remain responsive during installation, with additional operations queued.

• Open the release status matrix by default for rk status and bare rk in a
  terminal. Explore stage and destination evidence with the same inspection
  results used by the finite text and JSON reports.

• Add project-scoped use, install, and uninstall commands for executable
  packages, with Local, Homebrew, Pub, and public GitHub release sources.
  Bare commands open inline Fleury pickers; explicit sources and JSON support scripts.
  Local commands follow checkout edits, grouped commands switch together, and
  installation listings distinguish RK selection from effective PATH resolution.

• Replace init's terminal selector with the Fleury output matrix and a validated
  configuration review. Selected outputs read “Added”. Require Dart 3.10.4 or newer.

• Inline matrices keep the terminal background, use distinct active and focus
  colors, fit their content, and omit duplicate command labels. Keyboard
  navigation highlights one action; mouse capture stays disabled. Single-project actions close on success;
  multi-project matrices keep focus and stay open until Done. Init retains its
  configuration review, and unavailable choices explain why they cannot be used.

• Inline commands leave shell history intact and restore the prompt before
  reporting results. Ctrl+C and termination signals
  preserve their exit status while cancellation waits for in-progress work.

• Preserve the originating choice when returning from confirmation or details.
  Long reviews and errors support paging from their actions; init exposes
  discovery notes. Inspecting an unavailable source does not fail the command.

• Show archive locations after local-only builds.

• Add focused command help and one actionable next command for an unblocked
  unfinished release. Cancelling a release describes the current unit accurately,
  and cleanup lists recorded stage identities before confirmation.