v0.150.119

• Plan nix inside a container by two routes, now that chase asks for it: the host daemon's socket, as before, or a local-overlay store of the container's own over the host's, whose builds and fetches are the container's and so its network's to see -- spiked outside flong and working (single-user as your uid, sandbox off, the host adding paths harmless, the host collecting one an upper path uses not, so the launcher holds a GC root for each), with what flong would need: an overlay with a kept upper, allowed over /nix/store (e0d9a31)

v0.149.118

• Let a project's seccompPolicy override the declaration again, seccomp.deny included, by design: the declaration is the ready-made fit, written once for every project it launches, and a project's policy the tailored one, computed at launch for this checkout, so where they disagree the project wins; flong-seccomp project is given namesFor's names once more, deny already taken out, in place of d73509f's projectNamesFor and its -X lines, which are gone, so a project allow puts back a call seccomp.deny removed and a log logs one, as before d73509f, and 8a01ab3's notice ("seccomp.deny refuses what the project allows") is gone with the binding it said; base none now starts from no names at all rather than from the declaration's denies, and is still refused when its allows leave nothing; log, nolog, base none and flong-seccomp resolve are otherwise as they were, their line syntax unchanged; the option's doc, SeccompProject.names, Seccomp.deny and DESIGN say the project's lines override the declaration, deny included, and that a declaration which must keep a call refused leaves seccompPolicy empty or has its commands refuse such a policy, in place of the binding, the "until 2026-10-02" note and the old "deny as -name", which described a names file that never carried deny's entries; the project-declared-deny-* golden cases and strict-deny-ptrace.names give way to project-over-declared-deny, an allow and a log over expand-strict-deny's names, its policy checked when written against one rendered from flong-seccomp expand and its filter against compiling that policy directly, and rootless-b sees a declaration's deny refuse ptrace alone and a project's allow ptrace put it back, nothing said (d74285c)
• Answer the seccompPolicy review: base none whose allows leave nothing is refused by flong-seccomp project itself ("base none allows nothing: name at least one call with allow"), before the compiler meets the empty allow line of a policy nobody wrote, quirk 35 kept for the bash's own case of NAMES empty; a project allow the declaration's seccomp.deny overrides is said on stderr ("seccomp.deny refuses what the project allows: X...") and the launch goes on with the call refused, since until d73509f such an allow put the call back and an existing project that relied on it would otherwise lose it quietly -- a log naming one is not said, log @known naming every one; the option's doc says a project deny leaves a call to log unless nolog names it too, as project.zig always did, and that under seccomp.log every refused call is rendered log, deny's included, so the binding holds against the project's lines and not against seccomp.log; DESIGN puts the lost records down to printk's rate limit on the kernel log when no auditd runs, which journald's audit socket and auditd, reading the audit netlink, do not meet (audit_rate_limit is 0 by default; the backlog can still overflow in a large burst), in place of the audit rate limit; golden cases for both refusals and the notice, and rootless-b sees the notice from a live launch (8a01ab3)
• Let a project's seccompPolicy learn a policy at launch and keep the declaration's deny binding it: log X... renders each call of @known it names that the filter would refuse as log in place of the declaration's errno (allowed, and audited as type=1326), nolog X... takes names back out whatever order the two come in, and base none applies the lines to no names in place of the declaration's, so base none, a hot set's allow and log @known log every other call of @known while log @known alone learns against the profile; calls outside @known stay ENOSYS and the audit, tty and namespace filters stay hard; the declaration's seccomp.deny now reaches flong-seccomp project as -X lines after the names (policy.nix's projectNamesFor, the names file itself when deny is empty), so no project allow puts back and no log logs what deny took, as the option and SeccompProject.names already said and the expanded names file could not; flong-seccomp resolve ARCH NR names a record's arch= and syscall= by libseccomp's tables, x32 as audit reports it (x86_64's arch, 0x40000000 in the number), offered as the flake's packages..seccomp; with no log, nolog or base line the policy, its key and its filter are render's, byte for byte, and the golden tooling cases recorded from the bash pass unchanged but for the line refusal and the usage, which now name the new words; new golden cases each checked when written against a policy built from flong-seccomp expand and a direct compile, and rootless-b shows log and nolog live, a log learned from nothing, resolve naming what was logged, and a declared deny holding against a project's allow and log (d73509f)

v0.146.117

• Let exec name the container to the terminal for one launch: label:TEXT, at most once, replaces the container's name in OSC 666's vte.container.name and nothing else -- the hostname and every other use keep container -- 1 to 80 bytes of UTF-8 with no control character (C0, DEL, or a C1 code point, which VTE reads from UTF-8 as the byte, U+009C ending the sequence), refused otherwise as a bad forward: is; the mark writes a \ as \\ and a ; as \s, the escapes VTE reads in a termprop value, so the longest label, every byte escaped, with a ten-digit uid, still fits the 256 bytes; exec runs in the wrapper's half before the launcher marks the terminal, so the label is the only name it is told and the teardown's clearing mark is unchanged; basic shows it through script's pty, the plain container name without one, and each refusal; example labels and addresses are open-source ones (assemble's forwardBind test at example/shop's 127.101.170.171); .claude/ ignored (972fbbe)

v0.145.116

• Let a networked container ping: the mount helper, as U1's root in the container's network namespace before the mounts, writes its net.ipv4.ping_group_range from the lowest host gid U1 maps to the highest (ns.pingGroups), so iputils' plain ping opens an ICMP echo socket for IPv4 and IPv6 instead of a raw one it has no CAP_NET_RAW for, as on a NixOS host whose range is "0 2147483647" -- which U1 cannot write, the kernel refusing an id its writer's namespace does not map; a failure ends the launch as every helper step does, and basic-a pings 127.0.0.1 and ::1 from a networked session and is refused without a network (7a2f328)

v0.144.115

• Drop the gitlink f0024a5 committed by mistake, an agent's worktree under .claude/worktrees (e3e056d)

v0.143.114

• Let a container's forwarded ports bind one host address, interface, or both, as pasta 2026_07's ADDRESS%INTERFACE/ before -t and -u: network.forwardAddress and network.forwardInterface in the declaration, any IP address and any interface name -- which one is the caller's policy -- each null for every one as before, and exec's forward:BIND (ADDRESS, ADDRESS%INTERFACE, %INTERFACE, or empty for every address), at most once, replacing both for that launch, so a caller can give each workspace its own address; refused only where pasta could read more than an address or a name (a pattern at evaluation, decl.bindBad's parse in flong check and at launch), or with no network; hostLoopbackToSession reaches the container's loopback only from the host's 127.0.0.1, so at another address a listener inside on 127.0.0.1 alone is not reached, as DESIGN.md records with what 2026_07's auto no longer covers (the ephemeral range) and now parses (exclusions) (f0024a5)

v0.142.113

• Build the module's launcher with the pasta of flong's own locked nixpkgs, not the host's: what -t means changed in 2026_07 (auto a modifier on a port set, which an address may bind) and flong's checks run that nixpkgs', so a host on a release channel -- nix-config's 26.05 had 2025_09_19 -- launches with the pasta they ran; bubblewrap stays the host's (1a45a5e)

v0.141.112

• Open the README with what sets flong apart: it starts 10x faster than Docker and runs with less privilege by default (8ba730f)

v0.140.111

• Use the README's plain terms in every doc -- container for session, entrypoint for payload, rootfs for prepared root, the invoking user for caller -- and drop the history, so DESIGN.md, PLAN.md, the proofs README, decl.zig's doc comments (and the docs/declaration.md and decl-options.json made from them) and the module's descriptions say what flong is, not how it got there; compare with rootful and rootless Docker 29.8 measured on one desktop (about 10 against 120 ms, 19 against 200 with a network), with their capabilities and seccomp profile read from a live container and moby's default.json; and give the network example a container of its own with privateNetwork = true and forwardPorts = "auto" (d5cf056)

v0.139.110

• Drop "Setting it warns" from guard's doc comment in src/decl.zig, which 4a6ad0a took out of docs/declaration.md by hand but left at its source, so reference-fresh failed; decl-options.json regenerated to match (35ff9f1)
• Cut the README down to what a newcomer needs and say why flong over Docker: a comparison table, four plain terms (container, rootfs, entrypoint, hooks) in place of session, payload, prepared root and caller, one example per feature, one-line options and limitations, and the detail worth keeping moved to docs/reference.md in the same terms (793b028)
• Stop warning about a guard: since flong runs as the caller, every check the launcher makes -- workspace, binds, the depth rule, the guard -- is a consistency check and not a gate, and only the guard was warned about, so it goes and the test says a guard is not warned about, and the docs say a guard is a check as the launcher's others are (4a6ad0a)