Diagnosis (cross-repo refactor R1)
origin/main builds cleanly (cargo build --lib → Finished; verified at f79cde3 in a clean worktree with no ../t27, so build.rs skips regen). So this is a workflow contradiction, not a broken committed tree.
The contradiction:
build.rs — on every cargo build, if ../t27/target/release/t27c exists and a specs/*.t27 is newer than its gen/rust/<name>.rs, it runs t27c gen-rust and overwrites the tracked file in the source tree. Any dev who has t27c built gets a dirty gen/ after a plain build.lefthook.yml no-gen-edits — hard-blocks committing any gen/ change (exit 1, "VIOLATION L2").src/lib.rs includes gen via #[path = "../gen/rust/X.rs"], so gen/ must be committed to build on a clean clone (build.rs returns early when t27c is absent, e.g. CI/fresh clone).
Net: the build silently dirties gen/, but that dirt can never be committed — while the architecture requires gen/ to be committed. The three rules can't all hold.
Why it looks worse than it is right now
The feat/regen-final branch has a large in-progress refactor (lib.rs 9 → 106 gen modules, ~50 untracked gen/rust/*.rs, 20+ specs). That WIP tree compiles locally but a clean clone of it would miss ~31 referenced modules. That is the refactor's transient state, not a defect to fix here — this issue is only about the structural build.rs/hook contradiction, which persists after the refactor lands.
Options (maintainer's call — deliberately not changed mid-refactor)
- Commit gen/ as tracked generated artifacts (current de-facto model) + change
no-gen-edits from hard-block to advisory (a git hook can't distinguish faithful regen from hand-edit), and gate build.rs regeneration behind an explicit TRINET_REGEN=1 so plain builds stop dirtying the tree. CI enforces regen && git diff --exit-code.
- Treat gen/ as pure build output:
.gitignore gen/, always generate into OUT_DIR, require t27c on every build. Bigger change; breaks clean-clone builds without t27c.
Not touching code while feat/regen-final is live. Note: #58 ("main не собирается") appears stale — origin/main builds.
Diagnosis (cross-repo refactor R1)
origin/main builds cleanly (
cargo build --lib→ Finished; verified atf79cde3in a clean worktree with no../t27, sobuild.rsskips regen). So this is a workflow contradiction, not a broken committed tree.The contradiction:
build.rs— on everycargo build, if../t27/target/release/t27cexists and aspecs/*.t27is newer than itsgen/rust/<name>.rs, it runst27c gen-rustand overwrites the tracked file in the source tree. Any dev who has t27c built gets a dirtygen/after a plain build.lefthook.ymlno-gen-edits— hard-blocks committing anygen/change (exit 1, "VIOLATION L2").src/lib.rsincludes gen via#[path = "../gen/rust/X.rs"], sogen/must be committed to build on a clean clone (build.rs returns early when t27c is absent, e.g. CI/fresh clone).Net: the build silently dirties
gen/, but that dirt can never be committed — while the architecture requiresgen/to be committed. The three rules can't all hold.Why it looks worse than it is right now
The
feat/regen-finalbranch has a large in-progress refactor (lib.rs 9 → 106 gen modules, ~50 untrackedgen/rust/*.rs, 20+ specs). That WIP tree compiles locally but a clean clone of it would miss ~31 referenced modules. That is the refactor's transient state, not a defect to fix here — this issue is only about the structural build.rs/hook contradiction, which persists after the refactor lands.Options (maintainer's call — deliberately not changed mid-refactor)
no-gen-editsfrom hard-block to advisory (a git hook can't distinguish faithful regen from hand-edit), and gatebuild.rsregeneration behind an explicitTRINET_REGEN=1so plain builds stop dirtying the tree. CI enforcesregen && git diff --exit-code..gitignore gen/, always generate intoOUT_DIR, require t27c on every build. Bigger change; breaks clean-clone builds without t27c.Not touching code while
feat/regen-finalis live. Note: #58 ("main не собирается") appears stale — origin/main builds.