[V2:13] Add Proposal Selection Foundation - #27
Open
ritorhymes wants to merge 10 commits into
Open
Conversation
This was referenced May 5, 2026
ritorhymes
force-pushed
the
v2/13-proposal-selection-foundation
branch
2 times, most recently
from
May 7, 2026 05:18
6b52698 to
38a584a
Compare
ritorhymes
force-pushed
the
v2/13-proposal-selection-foundation
branch
2 times, most recently
from
May 9, 2026 20:10
b9ad7e2 to
c5cdc72
Compare
ritorhymes
force-pushed
the
v2/13-proposal-selection-foundation
branch
from
May 26, 2026 01:02
c5cdc72 to
4b766c7
Compare
ritorhymes
force-pushed
the
v2/13-proposal-selection-foundation
branch
from
June 21, 2026 22:41
4b766c7 to
eea3534
Compare
Add workspace-local `.build-eips.toml` loading and starter configuration. Introduce `config::ActiveRepo` to load the selected checkout’s `Build.toml`, validate explicit `-C` roots, and expose active repository context to later commands. Keep source materialization, initialization, and diagnostics in their owning later branches.
Add clean and dirty source materialization for the active repository and sibling content. Use `config::RepositoryUse` throughout the runtime path, preserve tracked working-tree materialization and `index_path`, and reject dirty active manifests in clean modes. Build, check, and serve prepare sources without fetching the active upstream; `changed` retains upstream fetching for comparison.
Add workspace initialization from the selected active `Build.toml`. Clone missing sibling repositories from declared locations and initialize a missing theme checkout from the manifest repository and pin. Preserve existing usable checkouts and fail without deleting unusable paths. Write `.build-eips.toml` only when absent and generate `WORKSPACE.md` for the initialized workspace.
Add `build-eips doctor` for validating workspace configuration, active `Build.toml`, managed sibling repositories, the local theme checkout, and required tools. Report ok/warn/fail diagnostics; invalid active manifests and unusable theme configuration fail, while expected sibling and theme-pin conditions can warn. Keep diagnostics read-only and leave execution and runtime behavior to later branches.
Resolve build, check, and serve source policy around local active sources, clean mode, remote siblings, build roots, and base URL precedence. Keep `--clean` and `--remote-siblings` as source controls and limit `--only` to supported local dirty modes. Route runtime commands through one resolved execution policy.
Run Zola with the editable `workspace/theme` checkout. Materialize tracked local theme files into prepared `themes/eips-theme`, load Zola and eipw configuration from that local checkout, and keep runtime commands independent of manifest network access.
Add prepared runtime build pipeline. Materialize active and sibling sources according to resolved execution policy, preprocess merged proposal content, prepare the local theme mount, and invoke runtime checks and rendering from `pipeline.rs`. Keep serve watch and sync behavior in the serve runtime branch.
Add server binding resolution and serve-only host/port flags for local Zola serve commands. Run Zola serve with the resolved server binding, optional base URL override, fast/force serve flags, and generated output directory. Add dirty serve watching for dirty active-repo paths and local theme changes. Clean mode disables active-repo sync but keeps theme sync.
Add build-eips preview for serving the existing resolved output directory without rebuilding or starting dirty sync. Reuse server binding resolution and preview-only host/port flags, and report missing output before binding the local server. Add a tiny_http static file server with safe path resolution, index-file fallback, basic content types, and preview path tests.
Add proposal number parsing, proposal path classification, and content-path helpers for flat and directory proposal layouts. Introduce the proposal-selection data needed by later editorial and targeted-rendering commands while leaving user-facing render selection, render-plan construction, and targeted rendering behavior to their owning later branches.
ritorhymes
force-pushed
the
v2/13-proposal-selection-foundation
branch
from
July 18, 2026 06:44
eea3534 to
e42c403
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds the internal proposal-selection foundation used by later editorial and targeted-rendering work. It introduces strict
ProposalNumberparsing, editorial selector classification, proposal content-path helpers for flat and directory layouts, and active-repo proposal-number-to-path resolution.It does not add user-facing
--only,[render].only, editorial commands, render-plan construction, selected-content pruning, link rewriting, dirty-path filtering, or targeted build/serve behavior. Review should focus on number parsing, selector classification, proposal-path semantics, and missing or ambiguous proposal resolution.proposal.rsand register it in the preprocessor module tree.ProposalNumberwith strict positive-number parsing, display, and serde support.content/123.mdand directorycontent/123/index.mdlayouts.Review Notes
This is an internal foundation PR. It provides proposal identifiers and content-path resolution, but it does not select content for rendering or modify the prepared source tree.
ProposalNumberaccepts only positive numeric values. Editorial commands need a separate classifier because editorial targets may be proposal numbers or repo-relative paths; this PR establishes that classification without adding the editorial command surface.Proposal content can use either a flat markdown path such as
content/123.mdor a directory path such ascontent/123/index.md. Active-repo lookup resolves a proposal number through those supported layouts and reports a clear error when no matching proposal exists or when the number maps ambiguously.V2:14 consumes these helpers for editorial target resolution. V2:15 owns user-facing targeted build selection and render-plan construction. V2:16 extends that targeted rendering behavior to serve.
Verification
src/proposal.rsforProposalNumber, positive-number parsing, serde behavior, and editorial selector classification.content/123.mdand directorycontent/123/index.mdlayouts.