Skip to content

Prepare for a public release: identity out of the code, one-line install - #10

Merged
ralyodio merged 2 commits into
masterfrom
public-cleanup
Aug 19, 2026
Merged

Prepare for a public release: identity out of the code, one-line install#10
ralyodio merged 2 commits into
masterfrom
public-cleanup

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

Two changes, both prerequisites for making this repository public.

The blog identity is configuration now

The post template hardcoded one person: a byline, a site name, a Mastodon handle, a GitHub profile and an email address, plus two CrawlProof account ids (an analytics site id and an ad slot id).

In a public repository that is worse than untidy. A fresh checkout would publish somebody else's name on every post, and meter that install's pageviews and ad impressions into an account it inherited from the repository rather than chose.

Identity now comes from a config file, read from $BLOG_CONFIG, then <blog dir>/blog.config.json, then ~/.config/cli-tools/blog.json, with the environment able to override any scalar field. The defaults are empty and the empty case is a good one rather than a broken one: no byline, no identity links, and no third-party scripts at all — which is the only fully smolweb-valid output this template has ever been able to produce.

  • blog-post config prints which file was picked up and what it resolved to.
  • blog-post new says so on stderr when it renders a post with no byline, because a silent anonymous post is the failure worth catching.
  • blog.config.example.json is the starting point; blog.config.json is gitignored.

Verified byte for byte: rendering with the maintainer's config reproduces the previous template exactly.

Also drops two colleagues' GitHub handles from gh-prs usage examples, removes a personal dev URL from the feed plugin doc, and ignores the usual credential file shapes.

One-line install, and a cli-tools front door

Installing this meant knowing to clone to a particular path, run pnpm, then run a script deliberately not named link. Fine for the author, poor front door for a public repo.

curl -fsSL https://raw.githubusercontent.com/profullstack/cli-tools/master/install.sh | sh

And a dispatcher, which is mostly there so the set has one name to install by — moshcode decides a tool is present by looking for a binary, so cli-tools on PATH is what makes moshcode install cli-tools and /cli-tools … work:

cli-tools list                 what is here, and what is on PATH
cli-tools update               pull, reinstall, relink
cli-tools link [--force]       symlink into ~/.local/bin
cli-tools aliases --install    merge the pit aliases
cli-tools <command> [args…]    run any of the others

Three things it is careful about:

  • The installer adopts a checkout that already owns these command names rather than cloning a second copy whose links are all refused as not-ours, with no explanation of why nothing changed.
  • update refuses to move a dirty or diverged tree instead of discarding work.
  • aliases --install merges: a name you bound yourself is kept, and the collision is reported rather than silently repointed.

Adds a tools plugin (/tools:install, /tools:list) alongside the existing blog and domain ones.

A correction

These docs had inherited the claim that PATH executables are needed because the pit runs aliases through zsh -c. The README already notes that stopped being true — current moshcode runs $SHELL -ic, which does source rc files. The new code and docs give the weaker, still-sufficient reason: a file works from every caller without anything having been sourced first.

The aliases are thin on purpose and none shares a name with a command, since a shell function beats PATH and would shadow the file. Both invariants are tests now, not comments.

Checks

  • 114 tests pass (was 98), typecheck clean.
  • Installer verified end to end into a sandbox: clean install links all 8 commands, re-run is idempotent, the adopt-existing-checkout path works, and the alias merge was tested against a copy of a real aliases.json.

🤖 Generated with Claude Code

ralyodio and others added 2 commits August 19, 2026 13:11
The post template hardcoded one person: a byline, a site name, a Mastodon
handle, a GitHub profile and an email address. It also hardcoded two CrawlProof
account ids — an analytics site id and an ad slot id. None of that is a property
of the tool, and in a public repository all of it is worse than untidy: a fresh
checkout would publish somebody else's name on every post, and meter that
install's pageviews and ad impressions into an account it inherited from the
repository rather than chose.

So identity now comes from a config file, read from $BLOG_CONFIG, then
<blog dir>/blog.config.json, then ~/.config/cli-tools/blog.json, with the
environment able to override any scalar field. The defaults are empty and the
empty case is a good one rather than a broken one: no byline, no identity links,
and no third-party scripts at all — which is the only fully smolweb-valid
output the template has ever been able to produce.

`blog-post config` prints which file was picked up and what it resolved to, and
`new` says so on stderr when it renders a post with no byline, because a silent
anonymous post is the failure worth catching.

Also replaces two colleagues' GitHub handles in gh-prs usage examples with
placeholders, drops a personal dev URL from the feed plugin doc, and ignores
blog.config.json plus the usual credential file shapes.

Verified: rendering with the maintainer's config reproduces the previous
template byte for byte. 98 tests pass, typecheck clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Until now installing these meant knowing to clone the repo to a particular
path, run pnpm, and then run a script whose name is not `link` for a reason
nobody would guess. That is fine for the person who wrote it and a poor front
door for a public repository.

So there is now `install.sh` behind the usual one-liner, and a `cli-tools`
command that fronts the set:

  cli-tools list                 what is here, and what is on PATH
  cli-tools update               pull, reinstall, relink
  cli-tools link [--force]       symlink into ~/.local/bin
  cli-tools aliases --install    merge the pit aliases
  cli-tools <command> [args…]    run any of the others

The dispatcher exists mainly so the set has one name to install by: moshcode
decides a tool is present by looking for a binary, so `cli-tools` on PATH is
what makes `moshcode install cli-tools` and `/cli-tools …` work.

Three things it is careful about. The installer adopts a checkout that already
owns these command names rather than cloning a second copy whose links are all
refused as not-ours, with no explanation of why nothing changed. `update`
refuses to move a dirty or diverged tree instead of discarding work. And
`aliases --install` merges: a name you bound yourself is kept, and the collision
is reported rather than silently repointed.

The aliases are thin on purpose and none shares a name with a command — a shell
function beats PATH, so an alias named after the file it wraps would shadow it.
Both invariants are now tests rather than comments.

Also adds a `tools` plugin (/tools:install, /tools:list) and corrects the
`zsh -c` rationale these docs had inherited: current moshcode runs `$SHELL -ic`,
which does source rc files. The reason to stay on PATH is the weaker one the
README already gives.

114 tests pass, typecheck clean, installer verified end to end into a sandbox.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

ThreatCrush Security Scan

3 finding(s)

MEDIUM: 1 | LOW: 2

Severity Rule Location
MEDIUM redos-nested-quantifier src/domain-free.ts:56
LOW insecure-temp-file test/blog.test.ts:73
LOW insecure-temp-file test/blog.test.ts:74

Snippets are redacted; ThreatCrush never prints matched credential material.

@ralyodio
ralyodio merged commit b85f7c4 into master Aug 19, 2026
4 checks passed
@ralyodio
ralyodio deleted the public-cleanup branch August 19, 2026 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant