<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Notes on Harbor Notes</title>
    <link>https://edge.uniscribeai.com/blog/</link>
    <description>Recent content in Notes on Harbor Notes</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <copyright>Copyright © 2026, M. Rowan.</copyright>
    <lastBuildDate>Wed, 18 Mar 2026 08:30:00 +0000</lastBuildDate>
    <atom:link href="https://edge.uniscribeai.com/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Keeping A Quiet Change Window</title>
      <link>https://edge.uniscribeai.com/keeping-a-quiet-change-window/</link>
      <pubDate>Wed, 18 Mar 2026 08:30:00 +0000</pubDate>
      <guid>https://edge.uniscribeai.com/keeping-a-quiet-change-window/</guid>
      <description>A good maintenance window is often defined by what does not happen.&#xA;No surprises in the dependency chain. No last-minute digging for paths or ports. No rushing through changes that should have been rehearsed earlier in the day.&#xA;The simplest way to make a window feel calm is to narrow the scope. One change, one verification path, one rollback path. The rest can wait for another round.&#xA;When the work is done, the notes should be clean enough that someone else could understand the result without reconstructing the whole evening from shell history.</description>
    </item>
    <item>
      <title>Small Defaults That Age Well</title>
      <link>https://edge.uniscribeai.com/small-defaults-that-age-well/</link>
      <pubDate>Tue, 10 Feb 2026 07:15:00 +0000</pubDate>
      <guid>https://edge.uniscribeai.com/small-defaults-that-age-well/</guid>
      <description>The defaults that hold up best are rarely dramatic.&#xA;They are the ones that make the next decision easier: descriptive names, plain file layouts, explicit ports, and configuration that can be read without hopping across five directories.&#xA;Many problems that look like reliability problems start as readability problems. If a system takes too much effort to remember, it will eventually be changed in a hurry.&#xA;That is why the smallest useful habit is often documentation that matches reality.</description>
    </item>
    <item>
      <title>Why Simple Status Pages Matter</title>
      <link>https://edge.uniscribeai.com/why-simple-status-pages-matter/</link>
      <pubDate>Sat, 24 Jan 2026 06:50:00 +0000</pubDate>
      <guid>https://edge.uniscribeai.com/why-simple-status-pages-matter/</guid>
      <description>When a service is healthy, a status page does not need to say very much.&#xA;It should load quickly, render well on an ordinary browser, and avoid adding new layers of complexity just to announce that things are normal.&#xA;Simple pages also age well. They survive redesign fatigue, script breakage, and dependency churn because there is very little there to fail.&#xA;In practice, that is often enough.</description>
    </item>
  </channel>
</rss>
