• Introduction
• The Goal
• What Should Have Been Simple
• The First Problem: Workflow Permissions
  • The fix
• The Second Problem: Wrong Repo Target
  • The fix
• The Third Problem: SSH vs HTTPS
  • The fix
• The Fourth Problem: Secrets
  • 1. GH_PAT
  • 2. PUBKEY
• The Fifth Problem: No Changes
• Verifying the Pipeline
• What Didn’t Matter
• What This Reinforced
• Why This Matters
• Final Thought

Friday, April 17, 2026

§Introduction

In Part 1, I described the idea:

Write locally → publish to Nostr → automatically render to a public site

That part is clean.

What isn’t clean is getting the pipeline working again in a new repository.

This article is about that reality.

§The Goal

Recreate the exact same system I built for:

blog.stantonweb.com

But now for:

stories.mycontinuum.xyz

Same model:

• Nostr as the content layer
• GitHub Actions as the automation
• GitHub Pages as the host

No redesign. Just reuse.

§What Should Have Been Simple

At a high level, the steps were straightforward:

1. Create a new GitHub repo
2. Copy over the workflow (fetch_articles.yml)
3. Set the correct repo target
4. Add secrets (GH_PAT, PUBKEY)
5. Push and let it run

In theory, that’s it.

In practice, that’s not it.

§The First Problem: Workflow Permissions

When I tried to push the workflow file, GitHub rejected it:

refusing to allow a Personal Access Token to create or update workflow .github/workflows/… without workflow scope

This is one of those rules you only remember after you hit it again.

§The fix

• Create a new Personal Access Token (PAT)
• Make sure it has:
  • Contents: Read and write
  • Workflows: Read and write

And importantly:

Scope it to the correct repository

§The Second Problem: Wrong Repo Target

The workflow I copied was still pointing to the old repo:

github.com/andrewgstanton/blog-stantonweb-site.git

So even with the correct token, it would have pushed to the wrong place.

§The fix

Update the remote inside the workflow:

**git remote set-url origin https://is.gd/wKrNTQ

Small change. Critical.

§The Third Problem: SSH vs HTTPS

Even though I normally use SSH locally, the push was going to:

**https://is.gd/NkqXpr

Which means:

GitHub was using a PAT, not my SSH key

That’s why the workflow permission error appeared during a normal git push.

§The fix

Switch the remote back to SSH:

git remote set-url origin git@github.com :andrewgstanton/stories-mycontinuum-xyz.git

Then push again.

§The Fourth Problem: Secrets

Two secrets are required:

§1. GH_PAT

This is the Personal Access Token used inside the workflow to push changes.

Important detail:

The same secret name can exist in multiple repos — with different values

So:

• blog-stantonweb-site → old token
• stories-mycontinuum-xyz → new token

§2. PUBKEY

This is the Nostr public key used to fetch articles.

In my case:

nostr:@9wvc…guvd

The script handles conversion internally:

• accepts npub
• converts to hex if needed

So no extra work required.

§The Fifth Problem: No Changes

Once everything was wired up, the workflow ran…

…and did nothing.

Which is exactly what it should do.

Because:

The articles had already been generated locally earlier

So:

• no diff
• no commit
• no push

This is actually a good sign.

§Verifying the Pipeline

The correct way to test is simple:

1. Publish a new tagged article
2. Wait for the workflow (or run manually)
3. Watch for:
   • new files generated
   • commit created
   • site updated

If that works:

The pipeline is live

§What Didn’t Matter

Interestingly, one thing I didn’t need to worry about yet:

the domain (stories.mycontinuum.xyz)

The pipeline works independently of DNS.

GitHub Actions:

• fetches
• builds
• commits

Whether the domain is configured or not is irrelevant at this stage.

§What This Reinforced

This system is simple in concept:

publish → tag → automation → site

But it depends on a few fragile pieces:

• token permissions
• correct repo targeting
• environment variables
• workflow configuration

Once those are correct:

it becomes completely automatic again

§Why This Matters

Most publishing systems hide this complexity behind:

• dashboards
• logins
• platforms

But the tradeoff is:

you don’t control the system

This approach flips that:

• you control the pipeline
• you control the data
• you control the output

(but it still isn’t trivial)

§Final Thought

Part 1 was about the idea.

Part 2 is about the reality.

Getting this working again wasn’t hard — but it wasn’t trivial either.

And that’s the point.

Once it’s set up:

it disappears

You go back to:

writing → publishing → tagging

And everything else happens on its own.

One article at a time.