1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
//! **Embedded assets, and the one thing that can silently replace them.**
//!
//! # The defect, measured on oden 2026-08-27
//!
//! `/home/rickard/git/facett` reported `git status --porcelain` as **clean — zero
//! lines** while **14 of its 14 Git-LFS-tracked files were 131-byte pointers**. Among
//! them, both fonts this crate and `facett-docview` compile into their binaries:
//!
//! ```text
//! facett-core/assets/fonts/Inter-Regular.ttf 131 B on disk, 876 576 B expected
//! facett-docview/assets/DejaVuSans.ttf 131 B on disk, 759 720 B expected
//! ```
//!
//! `git status` is silent about this **by construction**: the LFS clean filter passes a
//! pointer through unchanged, so the pointer in the working tree hashes to the pointer in
//! `HEAD` and there is no diff to report. Every repo in the constellation that tracks LFS
//! at all was in this state — 61 files across 8 repos — and every one of them called
//! itself clean.
//!
//! What `include_bytes!` does with a 131-byte "font" is the interesting half: **it
//! compiles.** The build is green, the binary is smaller, and the failure surfaces as text
//! that does not shape, or as `egui`'s built-in fallback quietly standing in for the face
//! the design specified. No test that renders a *picture* catches it either, because
//! something is always drawn.
//!
//! # The guard
//!
//! [`is_a_git_lfs_pointer`] is a `const fn`, so the check runs in `const` context beside
//! the `include_bytes!` that needs it and the BUILD fails — the only place this can be
//! caught for free, on every host, before anything ships. One predicate for every embed
//! site in the workspace (LAW 5); the alternative is each crate re-deriving "what does a
//! broken asset look like", and the two answers drifting.
//!
//! Pair it with a size floor: a pointer is the common failure and the one that has
//! actually happened, but a truncated or empty asset is the same class of lie and the
//! magic bytes say nothing about it.
//!
//! ```
//! const FONT: &[u8] = include_bytes!("../assets/fonts/Inter-Regular.ttf");
//! const _: () = assert!(
//! !facett_core::asset::is_a_git_lfs_pointer(FONT) && FONT.len() > 4096,
//! "Inter-Regular.ttf is a Git-LFS pointer or a stub, not a font — run `git lfs checkout`"
//! );
//! ```
/// The first line every Git-LFS pointer file starts with, per the v1 spec.
///
/// The whole file is three short lines — `version`, `oid sha256:…`, `size …` — and the
/// version line is fixed text, so matching its prefix is exact rather than heuristic.
const LFS_POINTER_MAGIC: & = b"version https://git-lfs.github.com/spec/v1";
/// **Are these bytes a Git-LFS pointer instead of the asset they claim to be?**
///
/// `const` on purpose: the answer is wanted at compile time, next to the
/// `include_bytes!`, where it can stop a build instead of describing one.
///
/// Deliberately a prefix test and not a size test. A size floor belongs at the call site,
/// where the caller knows what "too small for THIS asset" means; a 131-byte PNG and a
/// 131-byte font need different floors, and this function must not pretend to pick one.
pub const