DEV Community: Arturo Ramírez-Montesinos Krogulski

StaSSH: My SSH Client Is Fine. The Rest of My SSH Life Wasn't

Arturo Ramírez-Montesinos Krogulski — Sat, 05 Sep 2026 17:02:06 +0000

I have been using SSH for a very long time.

SSH itself is not the problem.

OpenSSH is mature, ubiquitous, scriptable, compatible with just about everything, and already knows how to deal with keys, agents, jump hosts, port forwards, certificates, host verification and all the other things accumulated over decades of people administering Unix machines.

I had no particular desire to replace any of that.

My problem was everything around SSH.

After enough years and enough computers, your SSH setup stops being a configuration file and starts becoming archaeology.

Some hosts are in ~/.ssh/config. Some are in /etc/hosts. Some are in notes. Some are remembered by hostname, some by IP address, some by whatever nickname made sense six years ago. There are jump hosts, special ports, different identities, local forwards, commands you always run after connecting, and machines you vaguely remember require a particular ritual before they will cooperate.

And, of course, some of this exists on one laptop but not another.

I wanted somewhere for my SSH life to live.

That became StaSSH.

StaSSH is a portable, offline-first workspace for SSH. It organizes hosts, folders, notes, tags, identities, jump chains, forwards and reusable workflows, and then lets the system OpenSSH client do the actual connecting.

Or, put another way:

StaSSH doesn't replace SSH. It remembers how I use SSH.

I wanted my SSH collection to travel

Portability was one of the original motivations.

I use several computers, and not all of them are particularly impressive computers.

Some are old machines that had been sitting unused for years. I kept them mostly because throwing away working computers felt like turning them into e-waste for no good reason. I eventually installed lightweight Linux systems on some of them, encrypted the disks, and turned them into what I think of as “losable” computers: machines I can take somewhere without being particularly upset if one gets damaged or disappears.

A fifteen-year-old laptop is still spectacularly overqualified for being an SSH terminal.

The problem is that modern desktop software increasingly disagrees.

StaSSH therefore has three frontends:

stassh       CLI
stassh-tui   terminal UI
stassh-gui   desktop GUI

The TUI in particular is deliberately light on resources. Rust helps considerably here, and I have also tried to keep open a path for building StaSSH for 32-bit x86 Linux. There are still perfectly functional old machines out there that have been abandoned by much of the modern application stack.

I don't need an old laptop to run a browser-sized desktop application just so I can remember the name of a server.

The TUI has another feature I particularly wanted. When StaSSH is itself running inside tmux or byobu, I can highlight a host and press t to open that connection in a new tmux window or byobu tab.

That turns an old laptop into a remarkably useful little administration station.

I can keep StaSSH in one tab, open machines into other tabs, jump between them, and never need a desktop environment at all.

Three interfaces, one program

The CLI, TUI and GUI are not three separate implementations that happen to read similar files.

StaSSH is a Rust Cargo workspace built around a shared crate called stassh-core.

Conceptually, it looks something like this:

                         stassh-core
                             |
               +-------------+-------------+
               |             |             |
              CLI           TUI           GUI
            stassh      stassh-tui     stassh-gui
               |             |             |
               +-------------+-------------+
                             |
                       system OpenSSH

The core owns the important concepts: hosts, folders, storage, identities, search, diagnostics, OpenSSH command generation, jump chains, forwards, Actions and so on.

The frontends are different ways of operating the same workspace.

That means I can use the GUI at my main workstation, the TUI on an ancient laptop, and the CLI from a script without maintaining three collections of hosts.

And underneath all of them is still the SSH implementation I already trust:

/usr/bin/ssh

StaSSH constructs the appropriate command, or a temporary OpenSSH configuration when something more complicated is needed, and runs the system client.

Existing SSH agents still work. Existing keys still work. Known hosts still work. OpenSSH remains OpenSSH.

This was an explicit design decision. I was trying to organize SSH, not reimplement it.

The portable part and the local part are different things

One of the problems with carrying an SSH setup between computers is that not everything should be portable.

StaSSH's default configuration lives under:

~/.ssh/stassh/

with three files:

vault.json
local.json
secrets.json

vault.json describes the portable workspace: folders, hosts, usernames, ports, notes, tags, jump chains, forwarding definitions, Actions and references to identities.

It is deliberately plain JSON.

local.json, on the other hand, answers questions specific to the computer currently running StaSSH.

An identity in the portable vault can be represented by the fingerprint of its public key. The corresponding private key itself is not stored in the StaSSH vault. local.json can say where that identity actually lives on this particular machine.

So one laptop might map an identity to:

/home/arturo/.ssh/work_ed25519

while another computer can map the same fingerprint to a different local path.

The portable workspace knows which identity I mean.

The local configuration knows where this computer keeps it.

The same idea applies to local programs used by StaSSH Actions. An Action can refer to a capability such as a VNC viewer without embedding the executable path used on one particular computer.

This separation turned out to be one of the more useful architectural decisions in the project.

Copy the portable workspace to another computer, configure its local mappings, and the meaning of the SSH estate travels without pretending every computer is identical.

About passwords

There is also an optional secrets.json.

I want to be careful about what this is, because StaSSH is not intended to be a password manager.

Most of the time I connect to my machines with SSH keys, and most routine work does not require a password at all. But occasionally I need to do some administrative work with sudo.

The strange thing about passwords for machines you have personally configured is that there is a category of password you don't exactly remember, but you recognize instantly when you see it.

While configuring a particular machine I may have typed its password fifty times. Six months later, among dozens of hosts, I cannot necessarily recall it cold.

Show it to me once and I think:

“Oh, right. That one.”

And then I remember it for the rest of the session.

That is the niche secrets.json is intended to cover: host-associated fallback operational secrets, not your entire digital life.

Secret values stored there are encrypted; the surrounding metadata should still be considered private. I would not put my banking passwords in it, and I don't recommend anyone else does either.

Then there are Actions

Hosts are only half of an SSH workflow.

Quite often I don't merely want to connect to a computer. I want to do the thing I normally do with that computer.

That distinction led to StaSSH Actions.

An Action can do several things around an SSH session:

run something locally
        |
        v
prepare values or ports
        |
        v
start SSH, possibly with temporary forwards
        |
        v
run something on the remote machine
        |
        v
launch something locally
        |
        v
cleanup

Described like that, it sounds suspiciously like I have invented a complicated way to avoid typing commands.

So let me give the example that made the feature worthwhile for me.

VNC

Sometimes I want a remote graphical desktop.

Manually, that can mean starting a VNC server remotely, creating an SSH tunnel, choosing a free local port and then launching the correct viewer against it.

With a StaSSH Action, I select the host and choose:

VNC forwarded

and the VNC window appears.

The Action can start x11vnc remotely, create a temporary SSH forward from an automatically selected local port to port 5900 on the remote machine, and launch my local VNC viewer against that port.

StaSSH has not become a VNC client.

It has simply learned how I use my VNC client.

A feature I didn't add

While discussing StaSSH, I realized that it couldn't upload a file to a remote machine.

The obvious response would have been:

Add file transfer to StaSSH.

That would mean starting down the road toward file browsers, transfer queues, progress interfaces and eventually some sort of built-in SFTP subsystem.

Instead, I asked the coding agent to write an Action.

The repository now contains a Send file to home example. The Action invokes a small local helper, lets me choose a file and sends it to the selected host using scp.

StaSSH itself did not acquire an SCP implementation.

It didn't acquire a file manager either.

The new workflow was mostly composed out of software that was already there.

That is increasingly how I think about Actions.

They are an escape hatch from feature creep.

I don't particularly want StaSSH to grow its own VNC client, browser, file manager, database frontend and every other application I might conceivably use through an SSH connection.

Those programs already exist.

StaSSH can remember how I use them together.

The first file-transfer Action is intentionally simple. One direction I am considering for a future release—possibly the 1.2 timeframe—is tighter SCP support, particularly so transfers can automatically inherit more of StaSSH's identity and jump-host knowledge.

But even this simple example demonstrated the point nicely.

A missing feature did not necessarily require a new subsystem.

It required a new recipe.

Actions are deliberately written as JSON

There is currently no graphical Action designer.

That is intentional.

Actions can combine local commands, environment values, port allocation, SSH forwards, remote commands, local applications and cleanup. A GUI capable of expressing every possible combination would either become surprisingly elaborate or gradually restrict the underlying model to whatever the GUI happened to support.

So Actions are JSON-first.

There is a HOWTO-Actions.md file in the repository explaining the schema, template variables, capabilities, forwarding and dry-run workflow.

You can write one yourself.

Or, this being 2026, you can give that document to an AI coding agent and describe what you want:

Read HOWTO-Actions.md and create an Action that...

That is also an interesting little experiment in interface design.

Not every interface necessarily needs to be optimized for a human to author manually.

A structured format can be easy for a human to inspect, easy for the application to validate, and easy for an AI agent to generate.

The important part is that the result remains visible.

It's still JSON. I can read it, change it, put it under version control if appropriate, and run the Action in dry-run mode to see exactly what StaSSH intends to execute before letting it do anything.

That feels like a much healthier use of AI than hiding another layer of magic behind a button.

A desktop workspace when I do want a desktop

None of this means I dislike graphical interfaces.

On my normal workstation I generally want one.

stassh-gui is built with Tauri and gives the same workspace a persistent host tree, inspector/editor panes and embedded terminal sessions.

Multiple SSH terminals can remain open at once. They can also be arranged into terminal layouts, including equal grids and layouts with one main terminal and smaller surrounding panes.

There is broadcast input for a layout when I genuinely want to type the same thing into several sessions, terminal find, full-screen panes, and indicators in the host tree showing which machines currently have sessions open.

The idea is not to turn SSH into a shiny dashboard.

It is to give an SSH-heavy working session somewhere to live.

The GUI's terminal sessions are real PTYs when not running in simulation mode, and real connections are still made using OpenSSH.

The desktop interface is another view over the same machinery, not a separate SSH universe.

Simulation mode

You may have noticed that all of the screenshot instructions in this article use --simulation.

That feature exists partly because screenshots of SSH tools are a privacy accident waiting to happen.

A realistic SSH interface naturally contains exactly the things you don't want to accidentally publish: hostnames, usernames, network addresses, notes, infrastructure topology and potentially terminal output from real machines.

Both the TUI and GUI therefore have a deterministic simulation mode.

It uses an in-memory demo workspace with fake folders, hosts, identities, forwards, jump chains, diagnostics and secrets. Simulated terminal sessions behave like tiny scripted SSH shells instead of making real network connections.

That makes it useful not only for documentation and demonstrations but also for visual regression testing.

The GUI test suite uses deterministic simulation data with Playwright screenshot baselines, so a feature originally useful for safely showing the program also became useful for checking that its interface hasn't quietly broken.

The files are the product

Another deliberate omission is built-in synchronization.

StaSSH doesn't require an account and doesn't have a cloud backend.

I already have ways to copy files between computers. Other people use Syncthing, Git, Nextcloud, Dropbox, rsync, a USB stick or whatever system they trust.

I don't want an SSH organizer to require me to adopt another synchronization service.

The portable files are meant to be portable as files.

That is decidedly unfashionable software architecture, and I rather like it.

There is also an important safety detail here: StaSSH frontends keep track of the vault.json state they loaded. If another program changes the vault on disk, StaSSH will refuse to blindly overwrite it and require a reload first.

Plain files should not mean careless files.

This project was written by an AI

There is one other unusual thing about StaSSH.

I did not write its code.

The project is part of an experiment I have been conducting with a different way of developing software. I decide what the program should do, define constraints, make architectural decisions, test it, reject things I don't like, discover missing features and keep steering the project.

The coding itself is done by an AI coding agent.

All of it.

Even if the change would take me one line, I ask the agent to make the change. Mixing my own quick fixes into the code would defeat part of the experiment.

I have spent decades programming by hand, so this is a strange way to work. But that is precisely why I am interested in exploring it seriously rather than treating AI as autocomplete with better publicity.

StaSSH itself has provided some nice examples of this relationship.

I wanted VNC to be one Action.

The Action machinery evolved around that requirement.

Then I noticed I wanted to transfer files.

Instead of telling the agent to build file transfer into StaSSH, I asked whether the existing Action system could express it.

It could.

For me, that design decision is still the human part of software development.

The interesting question was not:

Can you write an SCP feature?

It was:

Should StaSSH have an SCP feature at all?

What StaSSH is not

StaSSH is not a server-monitoring suite.

It is not Ansible.

It is not a password manager.

It is not a proprietary SSH service.

It doesn't want custody of my private keys.

It doesn't replace OpenSSH.

It doesn't require a cloud account.

And, unless an Action tells it to invoke one, it isn't trying to become my VNC client, browser or file manager either.

It is much closer to a memory and workbench for the SSH tools I already use.

That scope is deliberate.

There is always another remote-administration feature that could be added. At some point an SSH organizer can quietly turn into an operating environment.

I would rather StaSSH stay small enough to run happily on an old laptop.

Try it

StaSSH is open source, and the project is on GitHub:

StaSSH on GitHub

Linux packages provide the CLI, TUI and GUI together, or you can build the Rust workspace from source.

If your SSH world still fits comfortably in ~/.ssh/config, you may not need any of this.

But if your collection of machines has begun leaking into configuration files, notes, shell history, old scripts and your increasingly unreliable biological memory, StaSSH may look familiar.

SSH itself was never the problem.

I just needed somewhere to remember how I use it.

From Panorama to Planetarium: Building PanoPose

Arturo Ramírez-Montesinos Krogulski — Tue, 01 Sep 2026 21:43:30 +0000

Astronomical software can tell me precisely when the Moon rises.

Unfortunately, the Moon does not rise over a mathematical horizon from my observing site. It rises behind trees, roofs, hills, antennas, and whatever else happens to occupy that particular azimuth.

A planet may technically have risen while remaining invisible behind a ridge for another twenty minutes. A conjunction may happen low enough that one tree makes the difference between seeing it and missing it. A young crescent Moon may appear in a narrow gap in the landscape. An eclipse or planetary event close to sunrise or sunset may be theoretically visible but practically hidden.

For an observer, rise and set times are only theoretical until you know the shape of the real horizon.

That is the problem PanoPose is meant to solve.

PanoPose is a free and open-source Linux desktop application for taking a full-sphere 360° panorama of a real location, calibrating it against real altitude and azimuth coordinates, and turning it into something useful for astronomical planning — including a ready-to-install Stellarium landscape.

The basic idea is simple:

Take a picture of your horizon, teach the picture where it is looking, and let the planetarium use the real landscape.

Capturing the whole horizon used to be the hard part

Years ago, when I wanted a panorama of an observing site, I did it the traditional way.

Take a photograph.

Rotate the camera.

Take another.

Keep enough overlap.

Repeat until you have covered the full 360°.

If you also need a large vertical field of view, repeat the process at different elevations.

Then feed everything into Hugin or another panorama stitcher and hope that the seams, exposure differences, moving branches, clouds, and projection geometry all cooperate.

That still works, and for very high-resolution panoramas it may still be the right solution.

But consumer 360° cameras have changed the practical equation.

I now use an old Huawei CV60 connected to my phone and mounted on a monopod. The monopod is useful because a full-sphere camera sees almost everything, including whatever is holding it up, so minimizing the footprint makes the final image cleaner.

One shot gives me a 5376×2688 pixel, 2:1 equirectangular panorama covering the complete 360×180° sphere.

No stitching. No sequence of exposures. No carefully measured rotation.

You press the button and you have the panorama.

That makes capturing the site almost trivial.

There is still one problem.

The panorama does not know which way it is looking.

A photograph without coordinates

A 360° image can contain the entire landscape and still have no useful relationship with astronomical coordinates.

Which pixel is north?

Where exactly is the geometric horizon?

Is the camera perfectly level?

How much roll, pitch, or yaw is present?

If I see a tree in the panorama, what is its actual azimuth? If its canopy reaches a certain height in the image, what altitude does that correspond to?

That is where PanoPose begins.

Instead of editing the panorama as a flat rectangle, PanoPose places it on the inside of a sphere. You view the landscape from the same conceptual position from which it was photographed.

Over that sphere it can draw an Alt/Az coordinate grid, calculate the positions of astronomical objects for a chosen location and time, and let you rotate the panorama until the photograph agrees with the real sky.

The job is calibration rather than image editing.

First, let gravity tell you which way is up

The first step is getting the panorama level.

Buildings make this surprisingly easy.

Corners, columns, window frames, lamp posts, utility poles and similar structures provide vertical lines. Tilt the panorama until those features agree with the vertical grid lines in PanoPose.

If you are photographing somewhere completely natural and there are no trustworthy vertical features, you can create one.

Tie a cord to a tree, hang a rock from the end, and make sure the improvised plumb line appears somewhere in the 360° photograph.

Gravity has now drawn a vertical reference into your panorama.

It is crude surveying equipment, but physics does not care that the weight is a rock.

Once the panorama is level, one major uncertainty is gone.

Then let the Sun tell you which way you are looking

This is the part that makes the workflow much easier than I initially expected.

If the Sun appears in the photograph, PanoPose can calculate where the Sun actually was when the photograph was taken.

The application reads the timestamp and GPS coordinates from the image metadata when they are available. Location and time can also be entered manually.

Given those values, PanoPose calculates the Sun's expected Alt/Az position and displays a marker at that point in the spherical view.

Then the calibration procedure is essentially:

Switch to Align Target mode.
Find the photographed Sun.
Drag the panorama until the photographed Sun coincides with the calculated Sun marker.

That establishes the panorama's absolute orientation.

In practice, I have found that this two-stage procedure gets remarkably close:

Gravity gives you vertical.
The Sun gives you orientation.

For most purposes, that may already be all you need.

At night, the stars become precision instruments

If you want to refine the calibration further, the night sky provides an almost ridiculous number of free reference points.

Given an observer's geographical location and the time, the expected Alt/Az coordinates of stars can be calculated very accurately.

That means the stars are effectively lots of little precision Alt/Az gauges scattered across the sky.

PanoPose includes a Planetarium mode using a bundled catalog of bright stars. Set the correct location and time and the expected star field appears above the horizon.

You can then take a nighttime photograph — even an ordinary phone photograph if the phone is sensitive enough — that includes both stars and recognizable horizon features.

Perhaps a star appears just above a roof corner.

Perhaps another sits beside a particular branch.

Perhaps one is visible through a notch in a tree canopy.

If PanoPose predicts that star in exactly the same place relative to the landscape, the calibration agrees. If not, the remaining discrepancy tells you that there is still a small orientation error.

I found that leveling against vertical structures and aligning against the Sun was already extremely good. Stars are where you go when you want to chase the remaining tiny fraction of a degree.

So the full calibration hierarchy becomes:

Gravity gives you vertical.
The Sun gives you orientation.
The stars give you precision.

The geometric horizon is not your horizon

Once a panorama is calibrated, it stops being merely a picture of the site.

It becomes a directional model of the local horizon.

Suppose Stellarium tells you that an object rises at 05:42.

That means it crosses altitude 0° at 05:42.

But perhaps there is a ridge at altitude 6° in that direction.

Or a large tree.

Or two trees with a useful gap between them.

The question you normally care about is not:

When does the object geometrically rise?

It is:

When will I actually be able to see it from here?

A calibrated panorama lets the real landscape answer that question.

This is especially useful for phenomena that happen close to the horizon: conjunctions, young or old crescent Moons, Mercury and Venus, objects in twilight, eclipses near sunrise or sunset, and photographic compositions involving celestial objects and landscape features.

Sometimes the difference between seeing an event and missing it really is one particular tree.

Comparing one horizon with another

PanoPose can also load reference panoramas.

This is useful if you already have a calibrated panorama and later photograph the same location again.

Vegetation grows. Trees lose branches. Trees fall. New trees appear in gaps that used to be open. Buildings and other structures change too.

PanoPose can place the new panorama, called the target, over an older reference panorama and compare them directly.

You can blend the two images or adjust their opacity manually, but one of the most revealing comparison modes is Blink.

In Blink mode, PanoPose automatically alternates between the target panorama and the reference panorama.

The effect is simple but surprisingly effective.

A tree that has grown several degrees higher seems to jump between the two states. A missing branch becomes immediately obvious. A tree that has fallen simply disappears and reappears as the images alternate. Small changes that are difficult to notice while looking at two static images become conspicuous when the whole horizon flips back and forth.

That makes an older calibrated panorama more than an archive. It becomes a measuring reference for the new one.

Saving the calibration with the photograph

Once a panorama has been aligned, it would be annoying if the calibration existed only inside the current PanoPose session.

PanoPose can optionally save a copy of the loaded image containing the calibration metadata.

That includes the three pose angles together with time and location information. PanoPose uses GPano metadata where appropriate and also stores its own calibration information in XMP metadata.

Open that image again later and the application can recover the pose.

In other words, you only have to teach the panorama where it is looking once.

PanoPose can also import time and GPS information from another ordinary photograph without loading that photograph as the panorama itself. That can be useful when another camera or phone has the metadata you want to use for the calibration. It also makes it easy to show the star positions at the precise time you took that night-time reference photo.

Removing the sky sounded easier than it was

For a Stellarium landscape, it is necessary to make the real photographic sky transparent so that Stellarium can draw its own sky behind the landscape.

At first this looked like a problem that ought to have a pleasantly simple solution.

Start at the top of the image.

Identify sky-like colors.

Follow connected regions.

Perhaps look at brightness or gradients.

Remove everything that looks like sky.

That works wonderfully until it doesn't.

Clouds are not blue. Sunset skies are not blue. Haze reduces boundaries. Tree branches produce thousands of tiny edges. Bright gaps appear between leaves. Buildings have reflections. Thin objects cross the sky. A heuristic that works perfectly on one panorama can remove part of a tree on the next.

After trying simpler approaches, I eventually stopped trying to turn the problem into something simpler than it really is.

PanoPose uses the open-source skyseg-ncnn program for optional sky segmentation. It runs a small trained model specifically intended to distinguish sky from non-sky regions.

PanoPose deliberately treats this as an external optional tool rather than bundling it.

At startup, the application checks whether the skyseg-ncnn executable exists in the user's PATH.

If it does, the Remove Sky option becomes available.

If it does not, nothing else changes. PanoPose works normally without sky removal.

The resulting mask is converted into transparency, including partially transparent edges around trees and other fine structures.

For a Stellarium landscape, the result is much cleaner than simply placing the original photographed sky over the simulated one.

From panorama to planetarium

Once the panorama is calibrated, PanoPose can export it as a corrected full-sphere PNG.

The orientation is baked into the pixels while preserving the original equirectangular format and dimensions.

More importantly for astronomy users, PanoPose can export a Stellarium spherical landscape ZIP.

You provide a name, author and description, and PanoPose generates both the posed panorama texture and the landscape.ini file that Stellarium expects.

The current site latitude, longitude and elevation are included automatically.

If sky removal is enabled, the exported landscape can contain transparency so Stellarium's own sky appears above the photographed horizon.

The result can then be installed in Stellarium like any other custom landscape.

That closes the loop:

Real location → 360° photograph → calibrated Alt/Az panorama → Stellarium landscape.

It is not a panorama stitcher

PanoPose is deliberately narrow in scope.

It does not convert ordinary photographs into a spherical panorama.

It does not replace Hugin.

It does not attempt automatic computer-vision registration.

It is not a complete planetarium.

And its Planetarium mode is not intended to compete with Stellarium.

Its job is the missing step between those tools:

Take an existing 2:1 spherical panorama and establish precisely how that panorama corresponds to the real world.

Once that relationship exists, the image becomes much more useful.

A note about how it was built

PanoPose was developed entirely by OpenAI Codex from my requirements, testing, and iteration, and went from concept to v1.0 in about 48 hours on my $20/mo ChatGPT Plus plan. That is not really the point of the project, but it is worth stating for completeness. This is 2026; I wanted the tool, so I had the machine write it. Developers should probably get comfortable with the tools of the present before somebody starts calling them the tools of the past.

More interesting than who typed the code is whether the resulting software solves the problem.

For me, it does.

Getting PanoPose

PanoPose is free, open source, and currently a Linux application.

The project supports Linux packaging as .deb, .rpm, and AppImage builds.

Project repository:
https://github.com/arturormk/panopose-rust

The repository also contains a guided build/install script for people who prefer to build from source.

Two external programs are relevant:

ExifTool is used when writing calibration and metadata back into image files.
skyseg-ncnn is optional and is needed only for automatic sky removal.

The application itself remains usable without skyseg-ncnn.

The repository contains a script that will clone the ncnn and skyseg-ncnn repositories, patch the latter to work around a version mismatch, build the tool, and install it in your system.

The short version

If you want to try PanoPose with your own observing site, the workflow is roughly:

Capture or stitch a full-sphere 2:1 equirectangular panorama.
Open it in PanoPose.
Let PanoPose read the image's location and timestamp, or enter them manually.
Level the panorama using trustworthy vertical features — or an improvised plumb line.
Switch to Align Target.
Drag the photographed Sun onto PanoPose's calculated Sun marker.
Optionally use stars and Planetarium mode to refine the alignment.
Save the calibrated metadata if you want to preserve the pose in the image.
Optionally remove the sky.
Export the result as a corrected PNG or a Stellarium landscape ZIP.

A modern 360° camera makes the first step almost trivial.

The Sun and stars provide the calibration references for free.

PanoPose handles the bit in between.

If your astronomical horizon contains more than an infinite flat ocean, that bit may be useful.

Promptcraft for Play: Endless Conversational Adventures with ChatGPT

Arturo Ramírez-Montesinos Krogulski — Thu, 06 Nov 2025 11:04:38 +0000

Rediscover interactive storytelling in the age of AI.

Long before games had graphics, imagination did all the rendering.

Players typed things like open door, look north, or take lantern, and the computer responded with text. That was enough to create entire worlds. These were the classic text adventures — interactive fiction where the story unfolded through conversation.

With ChatGPT, this form of storytelling is reborn.

You can now play through worlds that don’t need predefined verbs or rigid parsers. You can simply talk:

“I shine the flashlight into the dark corridor and listen for movement.”

And ChatGPT will respond naturally, adapting to your intent, describing what you see, and evolving the story dynamically. Every playthrough is different — and the world exists only between you and the AI.

The Simple Prompt That Starts It All

Here’s the seed that unlocks a private adventure:

You are to create a short text adventure for me to explore.
Keep the entire world, map, and solution secret.
Once you have prepared it, tell me only that it is ready.
I will then begin exploring by asking questions or giving commands in natural language.
Never reveal what lies ahead — only describe what I perceive or what happens in response to my actions.
The goal is for me to solve the adventure through exploration and reasoning.

That’s all you need. The model will silently build a self-contained world — then let you explore it through natural dialogue.

Why It Works So Well

A good adventure is a closed world with hidden logic. The player discovers meaning by testing the unknown.

ChatGPT excels at:

Maintaining world continuity
Generating vivid, consistent descriptions
Reacting naturally to freeform language

Instead of a parser, you have a narrator — one that adapts in real time.

Adventures You Can Try

ChatGPT will ask you some followup questions about what kind of world you would like it to invent. You can give it broad strokes (“I'd like sci-fi“) and let it surprise you, or you can go for more detailed scenarios.

Sci-fi survival

“I awaken in a derelict space habitat with partial power. The rest of the crew is missing. Keep the layout and dangers secret.”

Mystery

“I am the caretaker of a silent manor. Each night, something unseen moves in the hallways.”

Noir detective

“Write a short noir mystery in 1940s Chicago. I’m a private investigator trying to solve a murder.”

Fantasy quest

“Build a world where I seek a relic guarded by riddles. Keep the map hidden.”

Each becomes a self-contained, conversational world — a microcosm of imagination that lives and dies in one chat.

The Joy of Exploration

You don’t have to win fast. You just have to wonder.

Ask questions, examine details, experiment. ChatGPT will respond to curiosity, not just commands.

These adventures aren’t nostalgic recreations — they’re new forms of storytelling, born from the conversation itself. They show what happens when a reasoning engine and a narrative engine merge.

It’s not just prompt engineering.

It’s promptcraft for play.

Software Curatorship: A New Practice for the Age of Intelligent Code

Arturo Ramírez-Montesinos Krogulski — Tue, 28 Oct 2025 18:44:44 +0000

Seven essays on how humans and AI can build meaning together

Introduction

The rise of AI-assisted coding has changed everything — and yet, our methods haven’t caught up.

Autocomplete turned into code generation, code generation into system design, and before long we found ourselves surrounded by software that writes software.

But who, then, preserves meaning? Who ensures that what AI produces still reflects human intent, ethics, and vision?

That question gave birth to a new discipline: Software Curatorship — the art and method of guiding AI-driven development so that systems remain coherent, transparent, and aligned with purpose.

Over the past months, I explored this idea through a series of essays on Medium. Below is a summary of that series, tracing the evolution from philosophy to methodology.

1. Prometaphysics: Where AI Meets the Edge of Consciousness

Read on Medium

A philosophical reflection on collaboration between minds — human and synthetic — and how creative intelligence might evolve beyond pure utility.

2. Coding in the Age of AI: What No One’s Telling You

Read on Medium

How automation changed the meaning of “software development.”
The essay introduces the concept of the curator — the human responsible for intent and coherence in AI-assisted creation.

3. The Making of a Software Curator

Read on Medium

From developer to curator: redefining authorship, responsibility, and skill in the era of generative code.

4. Coding vs. Curating: What Sets Curators Apart from Vibe Coders

Read on Medium

A practical distinction between “vibe coding” — letting AI generate code without direction — and true Curatorship, where the human provides architecture, intent, and moral compass.

5. Software Curatorship in Practice

Part 1 – The Method Behind Meaning
Part 2 – The Curatorial Loop
Part 3 – The Human at the Center

These three final chapters ground the philosophy in method.

They describe the Curatorial Loop — a continuous cycle of intent, generation, review, and reflection — and introduce the Curation Stack, a layered system where code, documentation, and rationale evolve together.

Why This Matters

Software Curatorship isn’t a metaphor. It’s a working methodology for aligning AI development with human purpose — one that integrates version control, documentation, testing, and reflection into a single living process.

It reimagines the developer’s role as a philosophical engineer: someone who maintains semantic coherence and ethical integrity while machines handle execution.

The Road Ahead

The goal of Software Curatorship is not to slow down automation — it’s to give it direction.

As AI systems become more capable, we’ll need curators to preserve the dialogue between what we build and why we build it.

I’m currently preparing the Software Curator’s Handbook, an open project that will document practical tools, YAML schemas, and examples for Curatorial development.

Follow me here or on Medium if you’d like to join the discussion.