{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicogpd26a6usvkxofblpqwgfj4xeefl5g3rsa3mxdlnqtafk44inq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mppnuimtrra2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidiilhldt6scqszpe3q3sriwg2t6wbwvfvg7rhaqpoqezleihgbju"
    },
    "mimeType": "image/webp",
    "size": 71764
  },
  "path": "/yashksaini/dev-log-8-hardening-the-orchestrator-a-week-of-making-dev-publish-resilient-14lh",
  "publishedAt": "2026-07-03T03:47:12.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "programming",
    "productivity",
    "opensource",
    "dev-publish",
    "nvim",
    "GitHub",
    "X",
    "LinkedIn",
    "Portfolio",
    "DevNotion"
  ],
  "textContent": "> Spent the week deep-diving into my dev-publish tool, focusing on durability and orchestrator resilience. 21 commits across two repos, with a massive cleanup of the publishing logic and some much-needed architecture documentation.\n\n##  TL;DR\n\nThere is a specific kind of satisfaction that comes from taking a tool you use every day and finally giving it the \"production-grade\" treatment it deserves. This week was exactly that. I spent most of my time in the guts of `dev-publish`, moving past the \"it works on my machine\" phase and into \"it works even if the world is on fire\" territory. With 21 commits and over 11,000 lines of code churn, I focused on making the publishing orchestrator resilient and the state durable.\n\n##  What I Built\n\nThe star of the show this week was dev-publish. If you’ve ever tried to automate cross-platform technical writing, you know that the edge cases are where the real pain lives. I pushed 16 commits here, touching about 45 files. The diff was pretty wild: +6,926 additions and -4,289 deletions. That net positive tells part of the story, but the deletions represent me ripping out brittle logic that just wasn't cutting it.\n\n###  Hardening the Orchestrator\n\nThe biggest win was a massive fix to make the publish state durable and the orchestrator resilient. In the previous iteration, if a network request to an API (like Dev.to) failed halfway through a multi-platform push, the state was... let's just say \"vague.\" I spent a lot of time in `src` ensuring that the orchestrator can now pick up where it left off. I also documented the published-flag semantics and re-run resilience in the README. It sounds like a small thing, but knowing that a re-run won't accidentally double-post your article is a huge weight off my mind.\n\nI also spent some time on the \"boring but important\" stuff. I normalized how tags are handled to make them safer across different platforms and implemented a much stricter resolution for cover images. If a local image is required but missing, the tool now yells at you immediately rather than failing silently mid-upload.\n\nOne of my favorite commits this week was `refactor: drop unused assetsDir config`. There is nothing quite like the feeling of deleting configuration options that you realized were over-engineered and unnecessary. It keeps the surface area small and the DX (developer experience) clean.\n\n###  Architecture and Docs\n\nI’m a firm believer that if you can't draw it, you don't understand it. I spent a chunk of time in `docs/diagrams` and actually embedded an architecture diagram directly into the README. It helps me visualize the flow between the local markdown files, the image resolver, and the final API calls.\n\nI also did a specific dive into the Dev.to integration. I added better validation for their API responses and exposed a properly typed error system. No more guessing why a request failed—now I get a clear, typed reason that the orchestrator can actually act upon.\n\n###  Keeping the Saw Sharp\n\nOutside of the heavy lifting on `dev-publish`, I spent a bit of time on my nvim config. This wasn't anything groundbreaking—mostly just keeping the environment healthy. I have a set of CI workflows that update all my plugins to the latest versions. It’s five quick commits that keep my editor snappy and ensure I’m not missing out on any new features or bug fixes in the Lua ecosystem. It’s the digital equivalent of cleaning your desk at the end of the day.\n\n##  Pull Requests & Issues\n\nYou might notice there are zero PRs this week. Since I’m the primary driver on these specific projects right now, I’ve been pushing directly to the main branches to keep the velocity high. It’s a bit of a \"move fast and fix things\" approach, but since I’m also the one writing the tests and the docs, the quality bar stays where it needs to be. No issues opened or discussions started either—just pure, unadulterated flow state.\n\n##  Tech Stack\n\nThis was a very TypeScript-heavy week. When you're building CLI tools and orchestrators, the type safety of TS is basically a superpower. Being able to define exactly what a \"PublishState\" looks like and having the compiler yell at me when I forget an edge case is the only way I stay sane.\n\nThe line count this week was pretty high (+6,935 / -4,298), which usually signals a mix of new feature work and heavy refactoring. I managed to maintain a 3-day streak, which felt good. It wasn't a \"grind\" week, but rather a few days of deep, focused work where I could really get into the zone.\n\nEven though my total language profile shows a massive amount of Python and Rust from past projects, this week was all about the TypeScript and Lua. It’s a reminder that as a dev, your \"current\" stack is often just whatever tool is best for the problem you're solving right now.\n\n##  What's Next\n\nNow that the orchestrator in `dev-publish` is stable and the state is durable, I want to start looking at expanding the platform support. The foundation is there, the architecture is documented, and the error handling is typed.\n\nI’m also keeping an eye on my Neovim setup. Those automated plugin updates sometimes introduce small breaking changes in the Lua APIs, so I might need to spend a morning next week tweaking my `init.lua` to accommodate any upstream shifts.\n\nIt was a solid week of building. Nothing beats the feeling of seeing a tool you built yourself get faster, stronger, and more reliable. Catch you in the next update!\n\n**Yash K Saini** — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source.\n\nGitHub · X · LinkedIn · Portfolio\n\n**Generated by DevNotion**",
  "title": "Dev log #8 Hardening the Orchestrator: A Week of Making dev-publish Resilient"
}