[{"content":"This idea came from using Obsidian. Some of it may carry over to other note-taking tools, but I am assuming features specific to Obsidian: aliases, unlinked mentions, and custom link text that fits the surrounding sentence.\nFor a while, I treated tags as the default tool for organizing notes. I added #investment to anything about investing and #security to anything about security. Tags were short, visible, and convenient: clicking one gathered related notes immediately.\nAs my vault grew, however, so did the number of questions that tags could not answer.\nWhat exactly does this tag mean? Why did I apply it to this note? How is it related to another idea? Tags are good at gathering notes, but they do not explain why those notes belong together. Now, before I add a tag, I first ask whether a wikilink can express what I mean.\nAnother post on this blog Properties and Tags: Two Layers of Note InformationThe rules I use in Obsidian to keep Properties as minimal machine-readable structure and tags as cross-cutting topics. September 1, 2026#pkm ↗ A tag has nowhere to hold an explanation Clicking #investment gathers my investment-related notes. The tag itself, though, cannot explain what I mean by investment. Does it mean long-term asset allocation, trading individual stocks, or even postponing consumption?\nA wikilink is different. I can create a note called [[Investment]] and keep revising its definition and criteria.\n# Investment To me, investing means exchanging resources I could use now for more choices in the future. - [[Asset allocation]] is less about predicting losses than deciding what I can withstand. - The difference between [[saving]] and investing depends more on when I will use the money. Investment is no longer just a label that opens a list. It becomes an idea I can develop. Other notes can link to its current definition, while backlinks show the contexts in which I have used the idea.\nMore tags create more choices Ten tags rarely cause trouble. With a hundred, I have to remember the existing vocabulary every time I write a note. Did I use #investment or #investing, #note-taking or #pkm? Retrieval has the same problem: I have to check several similar tags.\nThis is not a flaw unique to tags. If I turn every word into a wikilink, the same disorder returns in another form. Replacing a hundred tags with a hundred empty notes does not make the system simpler.\nThe useful difference is that a linked note can accumulate content. I create one only for an idea I expect to explain repeatedly, call by several names, or use as a reference point for other thoughts. If a term is not worth that much attention, I may need neither a link nor a tag.\nI need relationships, not only hierarchies Obsidian supports nested tags such as #investment/portfolio, so saying that tags cannot connect at all would be inaccurate. Nested tags can express a parent-child classification. The relationships I want to preserve are often more varied than that.\nThe less stable my [[cash flow]] is, the more important it becomes to choose an [[Asset allocation|asset allocation I can tolerate]]. The difference between [[Investment|investing]] and [[Saving|saving]] depends heavily on when I expect to use the money. The first sentence expresses a condition and a priority. The second states a distinction between two ideas. A hierarchy such as #cash-flow/investment cannot preserve either relationship naturally. A wikilink does not explain the relationship by itself, but it gives the surrounding sentence a place to do so.\nOne subject can have several names The same idea can have different names across contexts or languages. If I create separate tags for 투자, investment, and investing, I split one subject into three paths.\nIn Obsidian, I can add those names as aliases to one canonical note.\n--- aliases: - investment - investing - 투자 --- When I select the alias investing, Obsidian creates a link such as [[Investment|investing]], which still points to the same note. The Unlinked mentions section in Backlinks can also find occurrences of a note name and its aliases. I can discover places where I already wrote “investing” and convert only the meaningful ones into links.\nIf I need different wording in only one sentence, I do not need another alias.\nI have started reconsidering [[Investment|where I put my money]]. The destination remains Investment, while the sentence reads naturally in its local context.\nSometimes a tag is still the simpler tool At this point, removing tags altogether can sound tempting. In practice, that has not worked for me.\nTags remain a simple way to gather and filter notes under the same topic. If I want one view of security notes across software development, investing, and daily life, a tag is convenient. Creating a nearly empty [[Security]] note and linking every relevant file merely to reproduce that filter would be a detour.\nMy current rule is:\nUse a wikilink for a concept or subject that deserves its own explanation. Use a wikilink when I can state the relationship between two thoughts in a sentence. Use a tag only when I repeatedly filter for the same topic across different contexts. Use neither when I have no concrete reason to retrieve it again. For me, then, a wikilink is not a complete replacement for tags. It is the default I consider first. A tag makes a list; a wikilink creates a place for explanation and a path for relationships. When I return to a note, I need more than a list of similar things. I need enough context to understand why I connected them.\n","permalink":"https://blog.yoonho.site/en/wikilinks-before-tags/","summary":"\u003cp\u003eThis idea came from using Obsidian. Some of it may carry over to other note-taking tools, but I am assuming features specific to Obsidian: aliases, unlinked mentions, and custom link text that fits the surrounding sentence.\u003c/p\u003e\n\u003cp\u003eFor a while, I treated tags as the default tool for organizing notes. I added \u003ccode\u003e#investment\u003c/code\u003e to anything about investing and \u003ccode\u003e#security\u003c/code\u003e to anything about security. Tags were short, visible, and convenient: clicking one gathered related notes immediately.\u003c/p\u003e","title":"Why I Reach for Wikilinks Before Tags"},{"content":"When organizing notes, I mostly worried about where to put them. Once the folders were reasonably settled, another question remained.\n“How long should I keep revising this note?”\nIf I keep refining every note, the record of what happened at the time disappears. If I leave every note untouched after writing it once, new facts and ideas scatter into separate files. Creation and modification dates remain, but dates alone do not tell me what to do next.\nSo I tried placing notes on a time axis. What mattered was not when a note was created, but when my attention returns to it and when that attention closes.\nBullet Journal places notes along a time axis. To revisit another note, I move backward through that axis and depend on index pages. PARA moves expired projects and areas that no longer hold my attention into an Archive folder. Space bends as time changes. ACE separates time and space. It felt similar to my design. In my version, though, the Atlas side spans atlas/, notes/, and sources/, while the Calendar side maps to log/. All three methods can lead to changes in action across areas of life. I see value in that, but it is slightly different from the question I am trying to answer here.\nA creation date cannot explain a note\u0026rsquo;s time A file has a creation date. Obsidian can store dates as properties, and the file system records the last modification time. At first, I thought that was enough to explain the time of a note.\nBut two notes created on the same day can live very differently.\nMeeting minutes become a record of that day when the meeting ends. A thought captured in the inbox may be reviewed for several days before becoming another note or disappearing. A principle or concept I continue to use may be revised years later when I find new evidence.\nAlthough all three can share a creation date, attention returns to them in different ways. The time of a note is ultimately closer to an interval of independent attention and revision than to a single date.\nLink on this blog How I Found a Note System That Fits My Lifecycle (Korean)The earlier Korean post that led to this operating model. /pkm-note-taking-workflow/ ↗ I continue with where the actual file should live after deciding its temporal shape in the spatial-axis post.\nPoints, line segments, and rays Points, line segments, and rays are not mathematical models for measuring time precisely. Nor are they a classification system that forces notes into folders. They are operating metaphors for comparing the shape of returning attention.\nA point ({t₀}) is a note whose writing and completion happen within one interval of attention, with no separate round of revision afterward. Meeting minutes, logs of judgments made at the time, and preserved external sources are close to points.\nA point does not mean that writing took zero time. I might revise minutes throughout a four-hour meeting. If that one interval—the meeting and its immediate cleanup—closes and I do not revise the note again, it is still a point. Conversely, even a short document is closer to a line segment if I reopen it days later, revise it, and then finish it.\nA line segment ([t₀, t₁]) is a note that receives attention and revisions at distinct times but has an end condition. A research draft awaiting judgment and a project MOC with a completion point are close to line segments.\nThe right endpoint matters most. I review an inbox capture before its deadline, then create a new canonical note or delete the capture. A project MOC does not automatically become state: archived merely because the project ended. I keep it frozen only if it is no longer revised but remains useful for exploring or reviewing an area of interest. If it has no exploratory value, I clean up its references and delete it.\nA ray ([t₀, ∞)) has a beginning but no predetermined end. Principles I continue to use, concepts, and MOCs for ongoing interests are close to rays. In my vault, notes/ usually serves this role.\nA ray does not mean daily editing. I may leave it untouched for months. But when I encounter a new insight, a counterexample, or a changed fact, I can reopen and revise the same note. I have not closed off the possibility that attention will return.\nThe time axis is not a folder classification Notes on the same topic can have different temporal shapes.\nThe minutes from a security meeting in a project are a point. A security checklist used while the project is active may be a segment. Security principles that I keep refining across several projects are closer to a ray.\nSaving another note type such as meeting, security, or concept does not solve this problem. A type says what a note is about, but not when to close and reopen my attention.\nI decided not to attach a separate lifecycle property to every note. Folder structure can imply a temporal shape, but I do not force points, segments, and rays into folders or properties. created is the day a note was made, and file.mtime is only its latest modification time; neither preserves the full history of returning attention. This distinction is not a precise edit log. It is a model for deciding how I will treat the note next.\nWhat happens when there is no right endpoint The time model changed my inbox and logs most clearly.\nI used to leave inbox notes around because they might become useful someday. But a segment needs an end. If review turns a capture into an idea I want to develop, I create a new note under notes/. If it is external material, I make a new capture under sources/. I keep the original inbox capture when it has independent value; otherwise I delete it after checking its references.\nLogs are the opposite. There comes a point when I need to stop refining them to match my current thinking. If I rewrite the basis of a past decision using today\u0026rsquo;s standards, I can no longer understand why I made it. Even a record of a poor judgment is meaningful when it preserves the state from that time. Original material stays under sources/, the event context under log/, and only the reusable interpretation continues to evolve in a separate notes/ file.\nA ray carries a different responsibility. If I call a note alive but create a new file for every new piece of evidence, I end up with several canonical versions. For a principle I expect to keep referencing, I should return to the existing note, revise the wording, add counterexamples, and remove what no longer holds.\nIn short: preserve points, finish segments, and rewrite rays.\nDesigning the time of a note means designing when to stop When I hear “the time axis of notes,” I first think of creation dates, modification dates, and daily notes. I did too. In practice, what made organization difficult was not a lack of dates, but a lack of criteria for stopping.\nShould this remain a record of that moment? Should it be processed by a set time? Should I keep revising it whenever new evidence appears?\nAnswering those three questions reveals the next action without attaching complex states to every note. I stop treating a note that preserves the past in the same way as one intended to grow.\nThis distinction will probably change as I use it. For now, though, I think first about when attention returns and when it closes, not when the note was created. I continue with when a frozen MOC should remain or be deleted in the post about wikilinks and MOCs, and with the practical rules for separating original material, records, and thoughts I will keep revising in the post about sources, logs, and wikilinks. The time axis is less a way to organize dates than a way to think about the end of a note.\n","permalink":"https://blog.yoonho.site/en/note-time-axis/","summary":"\u003cp\u003eWhen organizing notes, I mostly worried about where to put them. Once the folders were reasonably settled, another question remained.\u003c/p\u003e\n\u003cp\u003e“How long should I keep revising this note?”\u003c/p\u003e\n\u003cp\u003eIf I keep refining every note, the record of what happened at the time disappears. If I leave every note untouched after writing it once, new facts and ideas scatter into separate files. Creation and modification dates remain, but dates alone do not tell me what to do next.\u003c/p\u003e","title":"How Long Should I Keep Revising a Note?"},{"content":"I spent a long time looking for a way to organize notes. I tried Zettelkasten, PARA, Bullet Journal, and ACE one by one. Each was clearly useful. But when I adopted one as-is, some part of it did not fit my life.\nSeveral times, I found myself spending more time fixing the system than writing notes. I split folders again, merged tags, added properties, then removed them. The structure grew more sophisticated, but deciding where a new note belonged remained difficult.\nInstead of searching for one more person\u0026rsquo;s method, I eventually turned the judgments I actually repeat into rules. I named the system You-Know Management, or YKM. It is also a small pun on reading Yoonho as “you know.”\nYKM is not a method for accumulating more of what I know. It is a way to manage how I came to know something, while preventing the record from that time and my present interpretation from overwriting each other.\nLink on this blog How I Found a Note System That Fits My Lifecycle (Korean)The earlier Korean post that led to YKM. /pkm-note-taking-workflow/ ↗ Why I do not put everything in one place What I want to preserve in my notes is not the amount of information, but the boundaries of change.\nWhat actually happened at that time? What did I encounter in the outside world then? How do I understand it now? What meaningful relationships connect it to other thoughts? Put all four in one file and the boundaries soon blur. Sentences summarizing external material mix with my interpretation. I rewrite a past judgment to match my current conclusion. Later, I have to separate the source from my own thinking all over again.\nYKM therefore divides the roles of memory.\nTool What it preserves Default behavior sources/ A capture of encountering the outside world at a particular time Preserve the original material and its provenance log/ What happened at a particular time and the judgment I made then Accumulate records without overwriting the past notes/ Current understanding, interpretation, and principles Keep revising as evidence and counterexamples appear wikilink A meaningful relationship between a note and a subject Reference it inside a sentence instead of copying it atlas/ An order and set of questions for reading several notes Explore through a path designed by a person Separating roles does not break connections. When each file\u0026rsquo;s responsibility is clear, changes are easier to see as I follow the links.\nThe time axis asks when I will revise again The time of a note cannot be explained by its creation and modification dates alone. What matters to me is when attention returns to the note and when that cycle of revision ends.\nI think of this in points, line segments, and rays.\nShape Attention and revision Examples Point ({t₀}) Writing and completion end within one interval of attention Meeting minutes, a decision made at the time, an external-source capture Line segment ([t₀,t₁]) Reopened several times, but with an end condition An active project map, a research draft awaiting judgment Ray ([t₀,∞)) No predetermined end; revised whenever new evidence appears Principles, concepts, and maps of ongoing interests Even meeting minutes written over four hours are a point if I stop revising them after the meeting. Conversely, a short document is a segment if I reopen and revise it over several days before finishing. What matters is not the duration of writing, but whether attention returns in separate intervals and whether there is an end.\nBullet Journal operates the present in chronological order. PARA moves projects into Archive as time passes. ACE separates Atlas and Calendar to look at knowledge and time. YKM also assumes time changes the next action for a note, but focuses less on writing order or storage location and more on when to revise the same canonical note and when to close it.\nI explore the time axis in more detail in How Long Should I Keep Revising a Note?.\nThe spatial axis decides how a file should be treated One file can live in only one place, while one note may relate to several topics. A note can be about security, privacy, and architecture at the same time.\nA topic-based folder forces me to choose one. Copies create the problem of deciding which file is canonical. In YKM, a folder does not describe the topic. It decides only how I should treat this file from now on.\nLocation Treatment inbox/ A capture I have not judged yet; review it within 30 days sources/ Original material created by someone else; do not rewrite the body log/ An event and judgment from that time; do not overwrite it with a current conclusion notes/ My interpretations, principles, and concepts that I will keep revising atlas/ A place for creating reading paths, not storing ordinary notes Before creating a note, I ask three questions rather than trying to guess its type.\nHave I not made a judgment yet? Put it in inbox/. Did it come from an external source? Preserve it in sources/. If I created it, will I keep revising it? Put it in notes/ if yes, and log/ if no. I do not create context or project subfolders under log/. New records go directly under log/; filenames, the body, wikilinks, and MOCs carry the context.\nAnd notes do not migrate. If a note takes on a different role, the original file has not transformed. A new note with a different responsibility has come into being.\nExternal material remains under sources/, while my interpretation becomes a new note under notes/. A record from a project remains under log/, while a reusable principle is extracted into a new note under notes/. An unreviewed AI draft stays in inbox/, while material adopted by a person becomes a new canonical note in the appropriate place. The two notes connect through a wikilink. If the old capture has no independent value, I delete it after checking its references. The role of each note stays stable from beginning to end instead of relying on file movement to carry meaning.\nI explain how I arrived at the spatial axis in more detail in Where Should a Note Live?.\nThe tools divide the questions abandoned by folders Simplifying folders was not enough. I also had to assign the questions they no longer answered to Properties, tags, wikilinks, and MOCs.\nTool Question it answers Folder How should this note be treated? Properties Which values should a machine sort and filter? tags Under which cross-cutting topics will I find it again? wikilink What is it connected to, and in what way? Atlas MOC In what order and from what perspective should I read? Keep Properties minimal The four default Properties are created, tags, sources, and aliases. I always include created and tags, and add sources and aliases only when they have values. I allow state: archived only on a MOC that I no longer revise but retain as a path for exploration or retrospection.\nI do not create values such as type, status, confidence, or updated. If the folder, filename, or body already tells me something—or if I never filter by the value—there is no reason to store it again. Instead of hiding low confidence behind confidence: low, I describe uncertainty under an Open questions section in the body.\nKeep tags for cross-cutting topics I use no more than three tags on a note, written in lowercase English kebab-case, with no hierarchy. Before adding one, I check three things.\nWill I retrieve at least three notes through this tag for the same reason? Is it a real topic rather than a note type, state, location, or project name? Is this note actually about the tag, rather than merely related to it? People, organizations, products, technologies, and events are proper names, so I connect them with wikilinks instead of tags. Tags are good at gathering results under the same topic, but cannot say why the connection exists.\nLet a wikilink state the relationship in a sentence More links are not automatically better. I create one only when a sentence in the body can explain the relationship between two subjects.\nKeeping sessions off the server makes [[statelessness-in-system-design|horizontal scaling]] easier. This sentence shows how statelessness relates to horizontal scaling, rather than merely saying that both notes share a topic. I do not twist the current sentence to match the title of the linked note. I show the role it plays in the present context.\nA MOC is a map, not an index Tags and search show what exists, but not what to read first. When I start wandering through several notes to explore a topic, when a tag exceeds 30 notes, or when I want one path through project records and reusable knowledge, I create a MOC under atlas/.\nA MOC shows the starting point, the current position, and where perspectives branch. Every link gets one line explaining why it belongs on that path. One note can appear in several MOCs because the file remains one while reading purposes differ.\nI cover the distinction between Properties, tags, and wikilinks in Properties and Tags: Two Layers of Note Information, and the relationship between links and MOCs in Connecting Notes with Wikilinks and MOCs.\nHow I operate it in practice The full YKM flow looks like this.\nCapture → inbox/ ↓ A person judges it. The file does not move. External material → Create a new capture under sources/ Event or activity at the time → Create a new record under log/ Interpretation to keep developing → Create a new note under notes/ ↖ Connect necessary relationships to the original capture, source, or log When a project produces reusable value → Extract 1–3 new principles under notes/ When exploration becomes costly → Create a MOC under atlas/ Once a week, I spend about 15 minutes emptying inbox/. I reconsider whether captures older than a month are worth protecting and extract one or two reusable principles from finished projects. Once a quarter—not more often—I review low-frequency tags, synonyms, and large tags that may need a MOC.\nI do not roll everything over automatically. The small amount of friction involved in rereading and choosing what remains acts as a filter. The purpose of the system is not to preserve everything, but to distinguish what can be reused from what should remain a historical record.\nFor a concrete example of dividing original material, historical records, and current interpretation, see Preserve Sources, Accumulate Records, Connect Thoughts.\nIt was ultimately about boundaries of responsibility I once wanted a folder structure that could explain every note I might write in the future. I no longer think that structure is possible. Topics multiply, interests change, and I may draw a different conclusion when I read the same material again.\nInstead, I keep each tool\u0026rsquo;s responsibility small. Folders handle treatment, Properties hold minimal structure, tags mark cross-cutting topics, wikilinks state meaningful relationships, and MOCs arrange reading order. sources/ protects someone else\u0026rsquo;s words, log/ preserves who I was at the time, and notes/ is where my current self keeps revising.\nI do not think YKM is the answer for everyone. At least for me, though, creating a new note no longer takes as much hesitation. I now spend a little more time writing and rereading notes than fixing the system. For the moment, that is enough.\nThe RULES.md I give AI agents working with this vault The block below restates only YKM\u0026rsquo;s operating rules in imperative form so it can be given directly to an AI agent. Adjust the vault path and validation command for the tool you use.\n# RULES.md — You-Know Management (YKM) This vault is a knowledge system designed to connect original material, historical records, and current interpretations without letting them overwrite one another. Follow these rules before creating or editing files. ## 1. Responsibilities of each tool - Folders express how a note should be treated. - Properties contain only the minimum structure a machine needs. - Tags express topics that cross multiple contexts. - Wikilinks express meaningful relationships between subjects and thoughts inside sentences. - An Atlas MOC guides the reading start, current position, and points where perspectives diverge. - Do not record the same information through more than one tool. ## 2. Location of a new note Ask these questions in order before creating a note. 1. Is it a capture that a person has not judged yet? Create it under `inbox/`. 2. Is it original material from an external source? Create it under `sources/` and do not rewrite the body at will. 3. If a person created it, will the writing continue to be revised? - Yes: create it under `notes/`. - No: create it under `log/` as a record from that time. - Create only MOCs and entry points under `atlas/`. - Store only images and attachments under `_attachments/`. - Store only rules, templates, and validation tools under `_system/`. - Do not create new top-level folders. - Create new `log/` records directly under `log/`. Do not create context or project subfolders. - Do not create a general-purpose `archive/` folder. ## 3. Notes do not migrate - When a note\u0026#39;s role changes, do not move or overwrite the existing file. - Create a new note in the location appropriate to the new role and connect it to the previous note. - Keep external material under `sources/`; write interpretation as a new note under `notes/`. - Keep events from the time under `log/`; extract reusable principles into new notes under `notes/`. - Before deleting an old capture, check its references and whether it has independent preservation value. - Before deleting a file, repair the wikilinks that refer to it. ## 4. Revision over time - Once an interval of attention closes, do not rewrite `sources/` or `log/` to match a current perspective. - Create a new note when the same event happens again or external material changes. - Keep updating the same canonical note under `notes/` when new evidence, counterexamples, or experience appears. - After a project with an end condition finishes, freeze its MOC with `state: archived` only when it retains value for exploration or retrospection. - If a note has no exploratory value, clean up its references and delete it. ## 5. Front matter Every knowledge note uses YAML front matter. ```yaml --- created: YYYY-MM-DD tags: [] sources: - \u0026#34;https://example.com/\u0026#34; aliases: - Another name --- ``` - `created` and `tags` are required. - `tags` is always an array containing zero to three items. - Add `sources` and `aliases` only when they have values. Do not leave empty arrays. - Use `state: archived` only on an `atlas/` MOC that is no longer revised but remains as a path for exploration or retrospection. - Do not create new properties such as `type`, `kind`, `status`, `reviewed`, `confidence`, `updated`, `title`, or `author`. - Record unverified facts and low confidence under an `Open questions` section in the body, not in Properties. - Record the next action in the body, not in a status property. ## 6. Tags - Apply tags only to cross-cutting topics that the note actually discusses. - Use no more than three tags per note. - Use lowercase English kebab-case. - Do not use hierarchical tags or `#hashtags` in the body. - Create a new tag only when at least three notes will be retrieved for the same reason. - Do not turn folder locations, note types, states, difficulty levels, or project names into tags. - Connect proper names—people, organizations, products, technologies, and events—with wikilinks instead of tags. - When a tag exceeds 30 notes, consider whether an Atlas MOC is needed before dividing the tag. ## 7. Wikilinks - Link only meaningful relationships. There is no minimum number of links. - Place links inside body sentences when possible and explain the relationship in natural language. - Do not twist the current sentence to match the title of a linked note. Use `[[target|expression in the current context]]` when necessary. - Do not link every noun. Link only subjects reused as evidence, contrast, or premises. - A source under `sources/` is valid without links. Notes under `notes/` that use the source create the relationships. - When AI suggests related links, suggest no more than three and do not force weak connections. ## 8. Atlas MOCs - Use `atlas/index.md` as the single entry point. - Consider creating a MOC when exploring a topic requires wandering through several notes or a tag exceeds 30 notes. - A MOC is not an automatically generated index. It is a map whose reading path is designed by a person. - Give every link one line explaining why it belongs on that path. - The same note may appear in several MOCs when the reading purposes differ. Do not duplicate the source file. - MOCs may connect to parent and peer maps. - Reveal the reading start, points where perspectives diverge, and missing counterexamples or cases. ## 9. AI collaboration - AI does not modify original material at will. - Keep AI-generated summaries and drafts under `inbox/` by default for human review. - Edit or create a specific canonical file directly only when the user explicitly requests it. - Distinguish facts, quotations, and interpretations. - Do not present unverified information as certain; record it under `Open questions`. - Leave confirmation of facts, selection of core claims, and project decisions to the user. - Inspect existing files and user-authored content first. Do not delete or overwrite unrelated material. ## 10. Check before saving - Was the new note created in the right folder from the beginning? - Was a new `log/` record created directly under `log/`? - Is the filename unique across the vault? - Does it have `created` and an array-shaped `tags` value? - Are there no more than three tags, and are they real topics? - Were proper names, types, states, and locations kept out of tags? - Does a note with evidence include `sources`? - Are facts, quotations, interpretations, and open questions distinguished? - Did you avoid moving an existing note or overwriting a past record from a current perspective? - Were references repaired before anything was deleted? When possible, run the vault validator after saving and report pre-existing violations separately from violations introduced by this change. ","permalink":"https://blog.yoonho.site/en/my-note-taking-system-ykm/","summary":"\u003cp\u003eI spent a long time looking for a way to organize notes. I tried Zettelkasten, PARA, Bullet Journal, and ACE one by one. Each was clearly useful. But when I adopted one as-is, some part of it did not fit my life.\u003c/p\u003e","title":"My Note-Taking System: YKM"},{"content":"As notes accumulate in Obsidian, three things that look similar are tempting to keep together: what an article said, what happened at the time, and my thoughts connecting the two. I used to think I could put everything in one note, add enough tags, and find it later.\nOver time, it became difficult to tell what came from the source, what reflected my judgment at the time, and what was still my current thinking that should be revised. I now divide the roles of records.\nsources/ preserves someone else\u0026rsquo;s words. log/ accumulates the state from a particular time. notes/ is where I keep revising my thoughts. A wikilink preserves a relationship inside a sentence without moving files. The point is not to classify more. It is to avoid storing one fact in two places.\nA file lives in one place, while meaningful relationships can keep extending through links.\nPreserve original material under sources/ sources/ stores work I did not create. It preserves what I learned from an external article, video, or document so I can refer to it later. The important part is not writing the perfect summary, but preserving which words and ideas came from the source.\nFor that reason, I do not rewrite the body of a note under sources/. I keep the referenced URL or a line identifying the source, along with what I read there. If my interpretation changes and I rewrite the old source note to match it, the boundary between source and interpretation disappears.\nThe word sources appears both as a folder and as a Property. Their roles differ. sources/ is where I preserve someone else\u0026rsquo;s original material. The sources property is a list of evidence—the URLs or source notes supporting the current note. The shared name does not mean recording the same information twice.\nIf an external article prompts a thought of my own, I do not append it to the source note. I create a separate note under notes/ for my understanding or for a judgment applied in another context. When I return to the source later, I can still distinguish what the author said from what I took from it.\nAccumulate the state from the time under log/ log/ is where I keep events and judgments from a particular time: what was discussed in a meeting, how far a project had progressed, or what decision I made about investing or daily life.\nA log is not a document that my present self rewrites after reevaluating the past. It preserves what I knew and chose at the time. When my thinking changes, I would rather continue the interpretation in a new notes/ file than rewrite the old log to match my current conclusion. Even a bad decision becomes useful retrospective material when it remains in its original state.\nThat does not mean every temporary memo belongs in log/. Something I have not judged yet goes to inbox/ first. After reviewing it, I create a new canonical note in sources/, log/, or notes/ and connect it to the original capture. If the capture has no independent value, I delete it after checking its references. It becomes a log only when the context of the event itself is worth preserving.\nI use the same rule when a project ends. Meeting notes and progress records stay under log/. Only principles or explanations reusable in other contexts are extracted into a separate notes/ file and linked back to the records. A project MOC is not automatically archived just because the project ended. I freeze it with state: archived only when I will no longer revise it but it remains useful for exploration or retrospection. Keeping historical records and reusable knowledge out of the same file matters.\nRewrite my own thinking under notes/ notes/ is where I keep writing that is mine and that I expect to revise: explanations rewritten in my own words after reading external material, principles found across several experiences, and concepts refined whenever a counterexample appears.\nThese are not documents I finish once and close. When I encounter new evidence, I return to the same note, revise its sentences, add exceptions, and remove what no longer holds. Creating a new file for every thought I intend to keep referencing would leave several similar canonical notes.\nSuppose I read an article claiming, “This is the cause of the incident.” I preserve the source under sources/. I record the incident I actually experienced, or the judgment from its meeting, under log/. If I want a principle that applies across several cases, I rewrite it in my own words under notes/. The three records cover the same subject but have different futures.\nA wikilink preserves a relationship in a sentence A tag answers, “Under what topic will I look for this again?” A wikilink answers, “What is it connected to, and in what way?” Instead of collecting every link in a list, I place it in the sentence that can explain its context.\nKeeping sessions off the server means [[statelessness-in-system-design|moving session state to an external store]]. This lets me write a natural sentence without forcing the title of the linked note into it. Someone following the link can also see that the two notes are not connected merely because they share a word, but because one judgment leads to the other.\nProper names and concepts work well as wikilinks. Instead of creating another kubernetes tag just because Kubernetes appears, I can link [[Kubernetes]] and explain in the sentence whether it is a cause, example, or application. aliases can connect other names for the same subject.\nI do not make a rule that every shared topic requires a wikilink. A tag is better when I repeatedly search for a topic across contexts. Conversely, a source note with no relationship to express is fine without a link. What matters is not the number of links, but whether the relationship will make sense when I read it again.\nQuestions decide where a new record begins When I encounter something new, I do not try to guess its perfect note type. I ask these questions in order to decide where the new record begins.\nQuestion Answer Location and future treatment Have I not judged it yet? Yes Review it under inbox/ and process it within 30 days After review, did it come from an external source? Yes Preserve the source and provenance under sources/ If I created it, will I keep revising it? No Keep the state from that time under log/ and append records If I created it, will I keep revising it? Yes Update it under notes/ as evidence and counterexamples appear Afterward, if another note has a meaningful relationship, I create a wikilink in the body. When I repeatedly read a group of notes together, I create a MOC under atlas/ and explain why each link should be read. Folders decide how a file is treated; links and MOCs create other reading paths without moving it.\nConsider an investigation into a Kubernetes incident. Official documentation belongs under sources/; the meeting and judgment at the time belong in log/YYYY-MM-DD-incident-report.md; a principle that applies across incidents belongs under notes/. Inside the notes/ text, I connect [[Kubernetes]] and related concepts. I create a MOC only when the need to revisit that path emerges. Separating the roles does not weaken the connections. It makes them clearer.\nSeparation does not break the connections I used to think dividing folders would scatter related things across different places. Now I think the opposite. When sources, records, and interpretations are mixed in one file, I have to decide what may be edited every time I open it. Separating roles makes the lifetime and responsibility of each note explicit.\nsources/ protects someone else\u0026rsquo;s words. log/ preserves who I was at the time. notes/ is where my current self keeps revising. A wikilink connects their meaningful relationships in sentences. If the spatial axis decides where a file lives, and the time axis examines when attention returns and closes, this post is about where actual records are preserved and how they remain connected.\nA note system was never a classification table that had to explain everything at once. Do not rewrite source material to match current thinking. Do not overwrite a historical record with a later conclusion. Revise only my own thinking as the evidence changes. At the moment, I think this distinction gives back a surprising amount of time.\n","permalink":"https://blog.yoonho.site/en/sources-log-wikilink/","summary":"\u003cp\u003eAs notes accumulate in Obsidian, three things that look similar are tempting to keep together: what an article said, what happened at the time, and my thoughts connecting the two. I used to think I could put everything in one note, add enough tags, and find it later.\u003c/p\u003e","title":"Preserve Sources, Accumulate Records, Connect Thoughts"},{"content":"When I first started using Obsidian, I thought more links meant a better note system. To be fair, the graph view looks ridiculously cool the moment you turn it on. Whenever I saw a related term, I made it a [[link]]. A denser graph looked more convincing too.\nLater, I followed those links and often could not remember why I had connected them. Some notes were linked only because they covered the same topic. The list of links was long, yet it had become even less clear where to start reading.\nNow I assign different questions to wikilinks and MOCs.\nA wikilink answers, “What is this connected to, and in what way?” A MOC answers, “In what order, and from what perspective, should I read?” Both connect notes. A link creates a relationship; a MOC creates a path.\nAnother post on this blog Properties and Tags: Two Layers of Note InformationThe rules I use in Obsidian to keep Properties as minimal machine-readable structure and tags as cross-cutting topics. September 1, 2026#pkm ↗ A wikilink is a reference, not a topic label A wikilink is not a tag that mechanically groups notes on the same topic. It lets me refer to one subject from several contexts without copying its contents, while the surrounding sentence explains how two ideas relate.\nKeeping sessions off the server makes [[statelessness-in-system-design|horizontal scaling]] easier. This link does not merely say that both notes are about system design. The sentence explains that statelessness enables horizontal scaling. Instead of twisting a sentence to match the title of the linked note, I would rather show the role that note plays in this context.\nFor people, organizations, products, technologies, and events that I expect to reference repeatedly, I create a named note and link to it. With aliases, different names can still lead to the same subject, and unlinked mentions become easier to find.\nBut I do not turn every noun into a note. Nor do I connect every note simply because it shares a topic. I link only relationships that I expect to use again as evidence, contrast, or premise. A note under sources/ can have no links at all when the preserved source has no meaningful relationship to express.\nA new role becomes a new note and a link The rule I settled on in the spatial-axis post is that “notes do not migrate.” When a note takes on a new role that belongs in another folder, I do not move the existing file.\nWhen a source gives me an interpretation of my own, I write a new note under notes/ and link the source as evidence. When I find a reusable principle in a log, I create a new note under notes/ and link the record from that moment. When reviewing an inbox capture produces a canonical note, I check the relationship between them, then keep or delete the capture. This keeps external material, records from the time, and my current interpretation from overwriting one another. Each canonical note stays in its own place, while links preserve the movement of thought. I describe this division in more detail in the post about sources, logs, and wikilinks.\nA MOC is a reading path built over links Tags and search show what exists. They do not tell me what to read first, where to examine a counterexample, or which practical case should come next. That is when I create a MOC (Map of Content) under atlas/.\nEvery link in a MOC gets one line explaining why it belongs on that path.\n- [[Core concept]] — Establish the premise for this path. - [[Counterexample]] — Find the conditions under which the premise breaks. - [[Application record]] — See how it worked in a real situation. A list of links with no reasons is not very different from a search result. A MOC is not an index; it is a map. It chooses a starting point, shows where I am, and reveals where perspectives diverge.\nOne note can appear in several MOCs. The file is not being copied; the reading purpose is different. The same note might be connected as a decision criterion in an investing MOC and as an automation example in an AI MOC. Each MOC only needs to explain why the note should be read there. MOCs can also connect to parent or peer paths.\nFrozen does not mean worthless A MOC also has a right endpoint on the time axis. But I do not automatically add state: archived when a project ends.\nIf it is a reading path I will continue to revise, I leave out state. If I will no longer revise it but it remains useful for exploration or retrospection in an area of interest, I freeze it with state: archived. If it no longer has exploratory value, I clean up its references first and delete it. If the fact that an idea or piece of information was wrong is itself useful, I reduce it to a short correction note explaining why. archived does not mean an abandoned map. It is a path that remains within my area of interest but is no longer being revised. Project completion, freezing, and deletion are not the same event.\nBefore deleting a note, I first repair the places that refer to it. If it contains original evidence, I replace the link with the source URL. If another canonical note has taken its place, I point there instead. Deletion is less about removing one file from the graph and more about cleaning up the relationships that file used to carry.\nThe reason to reread matters more than the number of links I used to think that a note was well connected when it had many links. Now I first ask whether I can understand the relationship when I follow one.\nI use a tag to collect the same cross-cutting topic. I use a wikilink to preserve a relationship between a thought and a specific subject. I make a MOC when several relationships need a perspective and an order for reading.\nConnection is ultimately about reasons, not quantity. If a link inside a sentence explains the relationship and one line in a MOC explains the reading purpose, even a sparse graph can be reused. The note system I want is not the one with the most connections. It is the one in which I can remember why they were made.\n","permalink":"https://blog.yoonho.site/en/obsidian-wikilinks-moc/","summary":"\u003cp\u003eWhen I first started using Obsidian, I thought more links meant a better note system. \u003cem\u003eTo be fair, the graph view looks ridiculously cool the moment you turn it on.\u003c/em\u003e Whenever I saw a related term, I made it a \u003ccode\u003e[[link]]\u003c/code\u003e. A denser graph looked more convincing too.\u003c/p\u003e","title":"Connecting Notes with Wikilinks and MOCs"},{"content":"For a while, I created a lot of Properties in Obsidian. If I recorded the type, status, confidence, and domain of each note, I thought I would be able to filter for anything later. I treated tags in much the same way: if a word looked relevant, I added it.\nAs the number of notes grew, the opposite happened. I recorded the same fact twice in a folder and a property. Tags and links pointed to the same subjects. A small change in policy meant updating several places together. I had built more classification, yet finding things again became harder.\nNow I treat Properties and tags as two separate layers, even though both appear in the same YAML block.\nProperties contain the minimum structure a machine needs to sort and filter. tags mark topics I want to find again across multiple contexts. The starting point is simple: write one fact in one place.\nWhile the spatial-axis post decides where a file belongs, this post looks at the structural and topical information placed on that file. I separated the relationships and reading paths handled by wikilinks and MOCs into the next post.\nLink on this blog How I Found a Note System That Fits My Lifecycle (Korean)The earlier Korean post that led to this operating model. /pkm-note-taking-workflow/ ↗ Properties are not a questionnaire about the note At first, I thought more properties would describe a note more accurately. I created values such as type, status, confidence, and domain. The problem was that describing something well and actually using that description later were not the same thing.\nIf I put a file under sources/ while also writing type: source, the same fact lives in two places. They may match at first, but eventually only one side changes. I ended up with notes whose property values were empty or disagreed with their folders. If I never build a list from a value, only its maintenance cost remains.\nSo I now use just four default Properties.\n--- created: 2026-09-01 tags: [] sources: - https://example.com/ aliases: - Another name --- created and tags are required. I add sources and aliases only when needed and do not leave empty arrays behind. The one exception is state: archived, which I allow only for a MOC under atlas/ that I no longer revise but retain as a path for exploration or retrospection.\nProperties live only in front matter YAML. I do not use inline key:: value fields. A property name keeps the same type across the entire vault, and tags is always an array. Mixed types break filters in Bases first.\nWhat matters here is not the number of fields but their nature. Properties contain values I will actually use for sorting or filtering. I do not move everything into YAML: not the title and author of a source, which read more naturally in the body; not a judgment that my confidence is low; not the next action in a project. The points, line segments, and rays of the time axis are models for thinking, not another type or status to store. Properties are not a survey of every characteristic a note has. They are a small schema for repeated computation.\nTags are topics that cross multiple notes A tag answers only one question: “Under what topic will I want to find this note again?” My rules are:\nUse between zero and three. Use lowercase English kebab-case. Do not create hierarchical tags. Do not duplicate folder names, note types, or states. Do not write #hashtags in the body. Create a new tag only when I will retrieve at least three notes for the same reason. The criterion that catches me most often is whether the note is actually about the tag. If a note covers an incident during a Kubernetes deployment, reliability may be a real topic. Adding dev merely because a development tool appears in the note would make the tag expand without limit.\nI do not use tags for proper names either. A tag such as #aws, #node-js, or #kubernetes does not tell me what role that subject plays. I link names as [[AWS]], [[Node.js]], or [[Kubernetes]] instead.\nIt can be confusing that tags appear among YAML Properties. In storage terms, tags is indeed a property. Its operating role is different, though. While created is a structural fact, tags is a topic filter that expresses multiple membership. Sharing a screen does not mean answering the same question.\nTags also have clear limits. A tag cannot easily preserve the reason or explanation for applying it. As their number grows, both tagging and retrieving by tag become harder. Tags alone cannot describe relationships between tags the way a sentence can.\nTags and wikilinks do not replace one another Tags are good at collecting results under the same cross-cutting topic. Wikilinks handle people, organizations, products, technologies, and events that I refer to repeatedly, as well as concrete relationships between two ideas. I do not connect every note merely because it shares a topic, and I do not turn a proper name into a tag when there is no topical role for it.\nThe conclusion is not that wikilinks are better than tags. Tags represent cross-cutting topics; wikilinks represent meaningful relationships. I continue with how I place wikilinks inside sentences and arrange their reading order with MOCs in the post about wikilinks and MOCs.\nSo where should this information go? When deciding where to record a piece of information, I work through the following order.\nChoose based on the question you will ask when retrieving the information, not its storage format.\nSuppose I am documenting an incident in which a Node stopped in Kubernetes.\nInformation to record Tool Reason Date the note was created created property A structural fact used for sorting and filtering by date URL of referenced documentation sources property The designated field for gathering evidence reliability, security tags Topics I will retrieve across other systems and projects [[Kubernetes]], [[Node.js]] wikilink Named subjects whose relationships can be explained in a sentence What went wrong and what to do next Body Information that needs to be read and judged in natural language With this division, one fact does not appear in two places. A new topic does not require moving the file, and a new subject does not require expanding the tag vocabulary.\nWhen classification looks necessary, I question it first Before creating a property or tag, I think about the cost of keeping it current rather than the feature it promises.\nCan it be computed from existing information? Are its boundaries clear? Will I have a real reason to update it later? If any of these questions is difficult to answer, I do not create the field. If search or a Bases expression can calculate it, I would rather not store it.\nThe same applies to tags. When a tag grows beyond 30 notes, I do not immediately split it into smaller tags. I first consider making a MOC. If the problem is that a large result set has lost its reading order, it needs guidance more than additional classification. Tags decide what to gather; a MOC guides what to read first.\nThis is not an argument for using fewer Obsidian features. It is an argument for keeping different features from doing the same job. Properties handle structure; tags handle topics. I continue with how I separate original material, historical records, and thoughts I will keep revising in the post about sources, logs, and wikilinks. When one tool answers one question, the rules become shorter and there are fewer places for them to drift apart.\nA note system should ultimately return time, not merely provide the satisfaction of having classified things well. I want to hesitate less when capturing something, understand why it appears when I find it again, and have only one place to update. For now, that is enough for me.\n","permalink":"https://blog.yoonho.site/en/obsidian-properties-tags-wikilinks/","summary":"\u003cp\u003eFor a while, I created a lot of Properties in Obsidian. If I recorded the type, status, confidence, and domain of each note, I thought I would be able to filter for anything later. I treated tags in much the same way: if a word looked relevant, I added it.\u003c/p\u003e","title":"Properties and Tags: Two Layers of Note Information"},{"content":"Anyone who keeps notes eventually runs into this question.\n“Where should this note go?”\nI changed my folders quite often because of it. I created a development folder, moved notes into project folders, and wondered whether a note belonged to productivity or PKM. Every new structure looked as if it might last. As the number of notes grew, the boundaries blurred again.\nLooking back, I did not need more folders. I was asking folders to answer too many questions.\nDividing space by topic was the problem A file cannot live in several folders at once. One note has one path.\nTopics do not work that way. Imagine a note about Obsidian security settings. It can be about obsidian, while also overlapping with security and privacy. A topic-based folder system forces me to choose one of the three.\nI could copy the file into several places, but that immediately creates another problem: which copy is canonical, and which one should I edit? If I keep only one file, I lose the paths into it from the topics I did not choose.\nWhen notes keep resisting folders, the classification may not be too coarse. I may have assigned a question with several valid answers to a tool that permits only one.\nLink on this blog How I Found a Note System That Fits My Lifecycle (Korean)The earlier Korean post that led to this operating model. /pkm-note-taking-workflow/ ↗ A folder answers one question So I redefined the spatial axis. Instead of topic, a folder now answers: How should I treat this note?\nIn my vault, a note\u0026rsquo;s place depends on where it came from and how I will handle it from now on.\nSpace Question Treatment inbox/ Have I not judged it yet? Capture quickly, review it, then empty the inbox notes/ Did it come from my thinking and experience? Keep refining it in my own words sources/ Was it written by someone else? Preserve the source and its original context; do not rewrite the body log/ Is this an event and judgment from that moment? Preserve the state from the time and append records without rewriting them atlas/ Is it a map connecting several notes? Give every link a reason and build a purpose-specific reading path This is not a perfect classification either. But “How should I treat it?” is easier to answer, and more stable over time, than “Is it security or privacy?” Topics keep multiplying and one note can belong to many of them. Where a note came from and how it should be handled leaves me with fewer choices.\nA folder is the one place where a note physically lives. Tags, wikilinks, and MOCs let me see that file from other perspectives without copying it.\nA topic is not a location Reducing the number of folders is not enough. I have to assign the questions abandoned by folders to the right tools.\nA tag answers, “Under what topic will I want to find this again?” Because a note can have several tags, they express multiple membership well. But tags become another classification hierarchy when there are too many, so I keep only cross-cutting topics that are genuinely useful to view together.\nA wikilink answers, “What does this connect to, and in what way?” A named subject such as Node.js or Kubernetes belongs more naturally in a link than a tag. What matters is not the number of links, but explaining inside the sentence why they are connected.\nI describe how I divide Properties and tags in the post about Properties and tags, and how I create meaningful relationships and reading paths in the post about wikilinks and MOCs. The more concrete rules for separating source material, records from the time, and my own thoughts are in the post about sources, logs, and wikilinks.\nA MOC (Map of Content) answers, “In what order should I read?” It is not an index that repeats a search result, but a map that shows a starting point and where perspectives branch. Every link explains why it belongs on the path. The same note can appear in several MOCs while remaining one file.\nNotes do not migrate The hardest problem left after defining the spatial axis was inbox/. It seemed reasonable to review a capture, then move it into sources/, notes/, or log/. But when a file move carries meaning, the file itself appears to change roles.\nI now use a simpler rule: notes do not migrate. When a different role requires a different folder, I create a new note in the place appropriate to that role.\nAn unreviewed capture remains in inbox/, while an adopted idea becomes a new note under notes/. External material remains in sources/, while my interpretation of it becomes a new note under notes/. A record from a project remains in log/, while a principle I expect to reuse becomes a new note under notes/. I connect the new and previous notes with a wikilink. If the old capture is valuable as evidence of change or provenance, I keep it. If it has no independent value, I delete it after checking its references. I do not move or duplicate a file simply because its topic changed. Adding or removing a topic is the job of tags and links, not a reason to move a file.\ninbox/ needs the most care under this rule. Because it accepts things I have not judged, it easily turns into storage. I review captures within 30 days, create a new canonical note in the right place or discard them, and do not postpone the decision by keeping the inbox file forever.\nSimpler folders left me with the work of writing I used to think every ambiguous note called for a new folder. Now I change the question.\nHow should I treat this note? Under what topic do I want to find it? What does it connect to? In what order should I read it again?\nWhen folders, tags, wikilinks, and MOCs each take one question, I need fewer structural overhauls. A new topic does not require a new folder, and a note that touches several interests does not need copies. The file has one place, while meaningful relationships can extend in several directions through sentences.\nWhat I wanted was not a folder structure capable of perfectly describing every note. I wanted a structure that made me hesitate less while writing and left only one place to edit later.\nThe spatial axis does not explain the full meaning of a note. It only decides how the file should be treated. Perhaps that limited responsibility is exactly what makes folders durable.\n","permalink":"https://blog.yoonho.site/en/note-spatial-axis/","summary":"\u003cp\u003eAnyone who keeps notes eventually runs into this question.\u003c/p\u003e\n\u003cp\u003e“Where should this note go?”\u003c/p\u003e\n\u003cp\u003eI changed my folders quite often because of it. I created a development folder, moved notes into project folders, and wondered whether a note belonged to productivity or PKM. Every new structure looked as if it might last. As the number of notes grew, the boundaries blurred again.\u003c/p\u003e","title":"Where Should a Note Live?"},{"content":"I recently looked through the folders of the projects I had been working on. There was this blog, a video production tool, a few small web services, and a desktop app. While building them one by one, I thought I was simply choosing whatever each project needed. Put together, though, the choices showed a clear pattern.\nI use TypeScript as a common language and keep the front end as lightweight as I can. When a server becomes necessary, I reach for Cloudflare Workers and D1. I do not put React everywhere; I use it only when there is a clear reason, such as a complex interface or video production. Whether a technology works well with AI-assisted development has also become part of the decision.\nThis is not a claim that this is the one correct stack today. It is closer to a record of how much complexity I am currently willing to carry after building several projects.\nTypeScript became the common language TypeScript appears across websites, CLIs, Cloudflare Functions, and video-rendering pipelines. That does not mean everything should be built with TypeScript. For an app like ssagal, Rust and Tauri were the more natural choice.\nBut after building several small services, I found that adding another language cost more than I expected. Relearning syntax was not the annoying part. The real cost was having different package managers, type systems, deployment scripts, and ways of tracking down errors. TypeScript is the language of the web, but for me it has also become the default working language when moving between projects.\nThat is why I also brought my CLIs and video pipelines into TypeScript. My Remotion work sits on the same path. I like that front-end code and the automation around it no longer feel like separate worlds.\nCan I build it together with AI? It is difficult to choose a technology today without considering AI. That does not mean handing over the entire codebase from the beginning. AI is already deeply involved in how I start an implementation, search documentation, write tests, and work through errors when I get stuck.\nWhen two options serve the project equally well, I first look at the language and tools that AI can read, write, and revise with reasonable consistency. Good documentation, enough examples, and a widely used package ecosystem matter more to me now. The time spent learning an unfamiliar technology is mine, but so is the time spent checking and correcting an AI that took the wrong path.\nThis does not make a new language, or a tool that AI still struggles with, a bad choice. If it is the only thing that makes the project possible, I should obviously use it. But when the goal is to finish the project, novelty alone no longer moves a technology up my list. For now, I favor tools I can understand and carry to completion together with AI.\nI start with a lightweight front end Many screens whose main job is to present content do not need to be large applications.\nThis blog is rendered as static pages with Hugo. Several record-keeping sites use Astro, while the wedding mobile invitation began with vanilla HTML, CSS, and JavaScript. The implementation differs, but the principle is the same: when writing or information is the focus, I start with a static site and keep deployment as simple as possible.\nI do not choose this because static sites look more impressive. I choose it because there is less to operate. I do not have to watch a server process, and I can more easily predict the result of a content change. I moved this blog from Ghost back to a static site for a similar reason. A tool with more features does not always make me write more often.\nOf course, a static site does not solve every problem. A service that keeps long-lived user state or changes continuously on screen will need a different approach. I just have not found many reasons to carry that complexity from day one.\nI add only as much server as I need Even a static site eventually reaches a point where it needs data. The guestbook in the wedding invitation needed somewhere to store messages. A report-writing web app needed data, files, and asynchronous jobs.\nFor these cases, Cloudflare Pages, Workers, and D1 fit well. I can add an API to the same deployment flow as the site and handle a small database or queue in the same place. The barrier to starting is lower than provisioning and managing a standalone server first.\nThere is still a rule behind this choice. “No server” is not the goal. I simply avoid creating a server to operate until I have a reason to operate one. I may need to reconsider when the data volume or processing time grows. At the current scale, just enough serverless functionality has been the most comfortable option.\nI use React only where it earns its place For a while, React felt like the default for any web project. But not every page needs the same amount of state management and component composition.\nReact and Remotion clearly earn their place in video work. Some videos need frames, subtitles, audio timing, and simulation results composed together. Another pipeline calculates scene duration from narration, then aligns subtitles and background music. At that point, breaking the UI into declarative and reusable components actually makes the work simpler.\nThe ssagal project, on the other hand, is a desktop app that places one small button on the screen and plays a sound. I did not add React. Plain HTML, CSS, and JavaScript handle the interface and playback logic, while Rust and Tauri focus on creating the window. Leaving out a framework was not giving up on technology. It was a decision to keep the boundary as small as the problem.\nA monorepo is not always the default either A monorepo is convenient when several apps share a design system or types. It works especially well when multiple sites share one design system, or when a CLI, shared schema, external-service integrations, and video packages need to move together.\nManaging dependencies with a pnpm workspace and separating common code into packages makes it easier to find what needs to change. Still, I do not think every tiny standalone project needs to begin as a monorepo. I can move into that structure later when the need appears, while folders and configuration created up front have to be maintained from the start.\nIn the end, it is about a size I can operate Looking across these projects did not leave me with a winning framework. I use TypeScript often, but I also built an app where Rust was the better fit. I prefer static sites, but add Workers and D1 when I need data. Sometimes I use React; when the screen is simple, I do not.\nIn the end, I seem to choose a stack by the amount of complexity I can operate, not by its feature list. Whether I can develop and verify it together with AI is now part of that calculation. I do not know whether these criteria will look the same a few years from now. For the moment, before adding another tool, I try to ask what problem truly cannot be solved without it.\nIn the next post, I want to look more closely at two choices that came from these criteria: why I chose Remotion, and why I left React out of a Tauri app.\n","permalink":"https://blog.yoonho.site/en/project-stack-retrospective-1/","summary":"\u003cp\u003eI recently looked through the folders of the projects I had been working on. There was this blog, a video production tool, a few small web services, and a desktop app. While building them one by one, I thought I was simply choosing whatever each project needed. Put together, though, the choices showed a clear pattern.\u003c/p\u003e","title":"The Tech Stack That Stuck as I Built More Projects"}]