kernel/ FOLIO

Jules Lin

Software developer
& careful maintainer.

Fictional sample profile

Readable systems.
Deliberate choices.
Room to maintain.

AN MRHTML TEMPLATE
JULES LIN / ENGINEERING NOTESPORTFOLIO 001

SOFTWARE, WITH THE EDGES CONSIDERED

Small tools.
Solid foundations.

I build for the next person who has to read the code. Sometimes, that person is me.

Explore the work

Interfaces / Local-first tools / Open-source thinking

Original fictional project studies

01 / THE SHAPE OF A SYSTEMA small local-first reading queueCONCEPT MAP
Reading queue architecture concept Reading view sends add and remove commands to a queue model. The queue model validates entries and writes to a local adapter. Saved results return to the view. An optional export boundary creates portable JSON. This diagram illustrates a fictional design, not running storage. Reading view Queue model Local adapter 01 / RENDER + INPUT 02 / VALIDATE + REDUCE 03 / WRITE + REPORT COMMAND PERSIST SAVED OR FAILED NEXT STATE BOUNDARY: OPTIONAL JSON EXPORT

View → Queue model → Local adapter. Each save reports success or failure; export is an explicit boundary.

command result

Boundaries before abstractions.

02 / SELECTED REPOSITORIES

Less surface.
More substance.

Three fictional tools.
The decisions are the story.

01

paperqueue

LOCAL-FIRST

A reading list that treats your saved links as a file you own.

TypeScript conceptStorage boundariesImport / export
Design notes

A small, explicit core

The sample architecture separates rendering from a pure queue model and a storage adapter. Validation happens before persistence, and the interface reports a failed save instead of pretending the item is safely stored.

Why not synchronize everything?

Local storage is simpler to understand but is device-specific, can be cleared, and can fail. An explicit export helps portability without promising background synchronization. Multi-device editing would need conflict rules and a different storage contract.

Concept only. This portfolio does not save links or run a reading-list service.

02

pathspec

BUILD TOOLS

A modest path matcher with an intentionally small grammar.

JavaScript conceptLiteral boundariesPredictable inputs
Design notes

Less syntax to get wrong

This fictional utility explores exact segments and a single wildcard. It avoids treating user input as executable regular expressions, making the supported behavior easier to document and review.

The tradeoff

A small grammar cannot express every filesystem query. That is an acceptable boundary for a build-step filter; a full glob library would be a better fit when recursive patterns, platform differences, and escape rules are required.

No matcher package is shipped or published. A real release would need a documented grammar and cross-platform tests.

03

patchwork

MAINTAINABILITY

A release-note workflow that keeps the reason beside the change.

Markdown conceptReviewable changesPlain files
Design notes

Keep the source reviewable

Each proposed change gets a short note: what changed, who needs to act, and where behavior differs. Small text files fit code review and keep release context close to implementation.

The tradeoff

Plain files are portable but can drift from the actual release. A real implementation should validate required fields in CI and let a maintainer review the assembled notes. Automatically generated prose should not make compatibility promises.

This is a workflow study. No release automation, repository integration, or publishing service is connected.

03 / FROM THE SOURCE

A readable boundary.

Illustrative JavaScript.
Copied as text, never executed here.

validate.js

// Accept only an explicit web URL.
function parseLink(input) {
  try {
    const url = new URL(input);
    if (!['https:', 'http:']
      .includes(url.protocol)) {
      return { ok: false };
    }
    return { ok: true, href: url.href };
  } catch {
    return { ok: false };
  }
}

persist.js

// The adapter decides how to write.
async function saveQueue(items, adapter) {
  try {
    await adapter.write(items);
    return { ok: true };
  } catch {
    return {
      ok: false,
      message: 'Save failed. Try again.'
    };
  }
}

Select and copy the example directly. It is demonstration code.

04 / CHANGE LOG

Always a
work in progress.

A fictional development journal. These entries illustrate how to document a decision, not a published package history.

  1. NOTE 003

    Make the boundary visible

    Separated the storage adapter from the model so the interface can describe a failed write without losing the draft.

    paperqueue / architecture
  2. NOTE 002

    Document what is unsupported

    Added explicit non-goals to the path grammar. A narrow contract is easier to keep than an implied promise.

    pathspec / documentation
  3. NOTE 001

    Start with the reason

    Moved the reader-facing impact to the first line of every sample release note.

    patchwork / workflow

GOOD SYSTEMS LEAVE ROOM FOR PEOPLE.

Let’s make the next
change a little easier.

This is a sample portfolio with no connected contact destination. Replace Jules’ introduction and add your verified contact or repository links before publishing.