mustflow 2.108.8 → 2.112.1

package/templates/default/locales/en/.mustflow/skills/writing-elegance/references/phrase-bank.md

@@ -0,0 +1,302 @@
+---
+mustflow_doc: skill.writing-elegance.phrase-bank
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: reference
+---
+
+# Writing Elegance Phrase Bank
+
+Use this reference only when `writing-elegance` is selected and the task needs stored expression
+patterns. Keep entries modular: short enough to recombine, general enough to survive outside the
+source text, and specific enough to shape future prose.
+
+## Modular Emotional Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| ko | 희망이라고는 느껴지지 않는 | with no trace of hope / where no trace of hope remained | Use to make a scene, tone, relationship, plan, answer, or silence feel emotionally depleted without overexplaining. | Avoid when the target writing needs neutral analysis, factual distance, or a lighter register. |
+| ko | 지켜주고 싶은 하나의 작은 | a small ___ worth protecting | Use before a fragile noun to make it feel intimate, precious, and emotionally worth preserving. | Avoid when the noun is not actually fragile, personal, or emotionally central. |
+| en | not quite believing | not quite believing that ___ | Use for incident notes, product analysis, narrative explanations, or support stories where an observed result is surprising enough that the writer has not fully absorbed it yet. | Avoid when the tone should be strictly factual, or when disbelief would undermine a verified observation. |
+
+## Memory and Sequence Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| ko | 시간 순서 없이 뒤섞인 | tangled out of chronological order | Use for memories, events, logs, emotions, or evidence that feel jumbled because their sequence has collapsed. | Avoid when the order is merely unknown, not experientially or analytically tangled. |
+| ko | 수없이 겹쳐진 프레임들 | countless overlapping frames | Use for memories, logs, screens, observations, event histories, or perspectives that appear as layered slices rather than a single clean sequence. | Avoid when there is only one source, one moment, or one unlayered observation. |
+| en | as it is | see ___ as it is, not as ___ remembers it | Use for legacy systems, relationships, decisions, stale assumptions, or postmortems where the current reality must be separated from an old mental model. | Avoid when there is no meaningful memory, nostalgia, or outdated assumption being corrected. |
+
+## Causal and Corrective Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| ko | 근원적인 해결책이 아니었다 | it was not a root-cause fix | Use for reviews, incident analysis, debugging notes, migration plans, or decision records where an action may mitigate symptoms without removing the underlying cause. | Avoid when the action actually eliminates the cause, or when a softer phrase such as "temporary mitigation" is more accurate. |
+| ko | 책에 나온 것과 실제는 많이 다릅니다 | what works on paper can differ sharply from reality | Use for design reviews, operations, policy discussions, implementation plans, or postmortems where a written rule, theory, or idealized design diverges from real-world behavior. | Avoid when the written model has already been tested under the same conditions, or when the gap is only speculation. |
+| ko | 빚어진 현상이다 | a phenomenon produced by ___ | Use for reports, media analysis, organizational change, technical adoption, policy outcomes, user behavior, or product shifts where a visible result should be explained as something produced by specific conditions. | Avoid when causality is uncertain, when the relationship is only correlation, or when a softer phrase such as "associated with" would be more accurate. |
+| ko | 더 시급한 건 ___인데 말입니다 | the more urgent issue is ___ | Use for reports, reviews, issue summaries, policy analysis, incident analysis, or technical explanations where a visible concern is real but a more immediate underlying issue needs attention first. | Avoid when urgency has not been justified, when the issue is merely different rather than more urgent, or when a neutral comparison would be more accurate. |
+| ko | 구조적 문제죠 | this is a structural problem, not a local one | Use for system design, organizational analysis, economic critique, product defects, operational failures, or repeated incidents where the cause sits in the surrounding structure rather than a single local mistake. | Avoid when the evidence only supports a one-off defect, when a specific local cause has already been proven, or when the phrase would inflate a small issue. |
+| ko | 부분적으로는 맞아도, 전체적으로 볼 때는 전혀 적합하지 않다 | locally reasonable, but globally wrong | Use for local optimization, team-level goals, component design, cost cutting, policy execution, or process choices that make sense in isolation but fail when the whole system is considered. | Avoid when the broader system impact has not been shown, when the local choice is also globally valid, or when the phrase would dodge a concrete local defect. |
+| ko | 무엇보다 우선입니다 | should come before almost anything else | Use for risk reduction, trust recovery, user safety, data protection, operational stability, or other priorities that should clearly precede secondary goals. | Avoid when the priority tradeoff has not been named, when everything cannot realistically be deprioritized, or when a hard ordering rule should be stated directly. |
+| en | the last straw | ___ was the last straw | Use for retrospectives, incident notes, churn analysis, team fatigue, support reviews, or operational risk where a final event matters because earlier strain had already accumulated. | Avoid when the event was the whole cause by itself, when no accumulation has been shown, or when the phrase would dramatize a minor inconvenience. |
+| en | not exactly the same | not exactly the same ___ as before | Use for migrations, policy changes, product shifts, audience changes, or operational updates where a surface may look familiar but the underlying character has changed. | Avoid when the thing is either unchanged or entirely different; use this for partial continuity with meaningful drift. |
+| en | remiss in not considering ___ | we were remiss in not considering ___ | Use for retrospectives, postmortems, review follow-ups, apologies, or decision records where the writer needs to acknowledge an omitted factor without sounding evasive. | Avoid when responsibility has not been established, when the omission belongs to someone else, or when a stronger accountability statement is required. |
+| ko | 계기였을 뿐, 더 중요한 원인은 따로 있는 | was only the trigger; the deeper cause lay elsewhere | Use for incident analysis, retrospectives, behavioral reviews, or product decisions where the visible event started the failure but did not explain why it became possible or severe. | Avoid when the trigger is also the root cause, or when deeper causality has not been investigated. |
+| ko | 문제의 근원이 드러난 이상 | once the root of the problem has come into view | Use for root-cause analysis, retrospectives, refactors, redesigns, incident follow-ups, or corrective plans where the underlying cause is now visible enough that the next corrective step should not be deferred. | Avoid when the cause is still speculative, when visibility is only partial, or when a formal finding needs stronger evidence before action. |
+| ko | 누구의 잘잘못을 가리기 전에 | before sorting out who was at fault | Use for incident response, conflict mediation, security events, outages, or urgent reviews where immediate containment or care must come before blame assignment. | Avoid when accountability is being permanently deferred, when fault has already been established, or when legal/compliance sequencing requires formal attribution first. |
+| ko | 두 번 겪기는 싫었다 | not something ___ should have to go through twice | Use for retrospectives, UX critiques, support notes, incident reviews, or process improvements where a painful experience should become a prevention principle. | Avoid when the experience is minor, intentionally repeatable, or when the point is personal preference rather than avoidable harm. |
+| en | wrong way | going about it the wrong way | Use for reviews, design critiques, process notes, or support explanations where the approach is flawed even if the goal is valid. | Avoid when the action is merely incomplete, unfamiliar, or one of several acceptable approaches. |
+| en | in place of that | in place of ___, they ___ | Use to contrast an expected action, explanation, or safeguard with what actually happened instead. | Avoid when there is no clear substituted path, or when the contrast would overstate intent. |
+| en | taken a turn for the worse | ___ has taken a turn for the worse | Use for product quality, operational health, team behavior, policy effects, or market conditions that have shifted from improvement or neutrality into decline. | Avoid when the situation was always bad, or when the change is only uncertain, temporary, or too mild for this phrasing. |
+| en | so gradually it was almost painful | ___ happened so gradually it was almost painful | Use for slow rollouts, migrations, degradation, investigations, meetings, or behavioral change where the pace itself becomes part of the burden. | Avoid when neutral timing language is more appropriate, or when "painful" would overstate a mild delay. |
+| en | skirting the real issue | skirting the real issue | Use for reviews, retrospectives, meetings, or critiques where the visible discussion avoids the underlying problem that actually needs a decision. | Avoid when the speaker is simply narrowing scope intentionally, or when the real issue has not been identified. |
+| ko | 말끔하게 처리했다고 생각하였다 | believed they had neatly disposed of ___ | Use for retrospectives, design reviews, policy critiques, incident analysis, or argument review where someone treats a hard objection, risk, or unresolved problem as settled when it has not actually been addressed. | Avoid when the issue was genuinely resolved, when the wording would imply bad faith without evidence, or when the remaining gap should be named directly. |
+| en | cover enough | ___ should have been cover enough | Use for security, abstraction, access-control, operational-safeguard, or process reviews where an existing protective layer should have made an extra workaround unnecessary. | Avoid when no real protective layer exists, or when the phrase would make an optional convenience sound like a broken guarantee. |
+| en | elaborate plot | set up such an elaborate ___ just to ___ | Use for architecture, security, product, or process critiques where the machinery appears disproportionate to the stated goal. | Avoid when the complexity is actually required by constraints, compliance, scale, or explicit user value. |
+| ko | 빈곤을 답습했고 | kept repeating the same pattern of ___ | Use for retrospectives, incident analysis, organizational debt, technical debt, or operational problems where the point is structural repetition rather than a one-off failure. | Avoid when the recurrence has not been shown, or when a single mistake is being overstated as a pattern. |
+| en | none of our doing | it was none of ___'s doing | Use for incident analysis, blame separation, support replies, or postmortems where a problem must be separated from a team, component, or actor without sounding evasive. | Avoid when causality is not established, when responsibility is shared, or when the phrase would read as deflection. |
+| en | trouble of a more than mild nature | trouble of more than mild significance | Use for risk reviews, incident notes, operational updates, design critiques, or project status where a problem is more serious than routine but still needs restrained wording. | Avoid when severity is already quantified, when the issue is minor, or when a direct severity label would be clearer. |
+| en | deep trouble | ___ is in deep trouble | Use for incident warnings, security reviews, project-risk notes, operational escalations, or blunt draft feedback where the situation is serious enough to require immediate attention. | Avoid when the tone must remain formal, when severity should be quantified, or when a precise failure mode should be named instead. |
+| en | spell trouble for ___ | ___ spells trouble for ___ | Use for risk reports, security reviews, project status, operational warnings, or stakeholder updates where an observed condition is a clear warning sign for a person, team, system, or outcome. | Avoid when the consequence is speculative, when a precise risk statement is required, or when the phrase would sound too casual for formal severity reporting. |
+| en | It starts simply enough, but then it turns out ___ | it starts simply enough, but then turns out to be ___ | Use for bug reports, retrospectives, investigations, scope reviews, or project updates where an apparently simple matter reveals deeper complexity. | Avoid when the complexity was obvious from the start, when the issue stayed genuinely simple, or when the phrase would excuse missed due diligence. |
+| ko | 원인이 되는 ___을 보여주지 않는다 | does not show the underlying ___ | Use for code reviews, root-cause analysis, critique, technical documentation, or research summaries where an output or symptom is described but the mechanism, cause, or basis remains missing. | Avoid when the underlying cause has already been shown, when the issue is only missing examples, or when "root cause" should be named directly. |
+
+## Communication and Framing Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| ko | 곧바로 본론으로 들어갔다 | got straight to the point | Use for meeting notes, interviews, investigations, reviews, or summaries where the writing moves directly into the main issue without preamble. | Avoid when the context needs a softer transition, background setup, or relationship-preserving introduction. |
+| ko | 뒤틀린 곳이나 막힌 곳이 없이 | without distortion or blockage | Use for prose, documentation, UX flows, process descriptions, architecture reviews, or code reviews where the structure moves cleanly without forced turns, hidden friction, or awkward interruption. | Avoid when the flow is merely short, when actual defects should be named directly, or when the phrasing would hide a necessary constraint, checkpoint, or guardrail. |
+| ko | 개념들을 적절하게 구분 지을 필요가 있다 | the ideas need to be properly separated | Use for documentation, reports, design explanations, reviews, or issue writeups where several concepts are being treated as one and need clearer boundaries before the argument can work. | Avoid when the ideas are intentionally connected, when separation would hide an important relationship, or when the real issue is missing evidence rather than structure. |
+| ko | 한 가지 생각에 대한 논의를 완전히 끝낸 다음에 | finish one line of thought before moving to the next | Use for documentation, review comments, explanations, meeting notes, or technical narratives where the reader needs one concept, claim, or step resolved before another is introduced. | Avoid when parallel comparison is the point, when interleaving is necessary, or when a shorter outline would be clearer than a full sequence. |
+| ko | 여러 개념이 복잡하게 뒤얽혀 있어서 | several ideas are tangled together | Use for draft feedback, requirements review, architecture notes, incident analysis, or explanation cleanup where confusion comes from multiple concepts being interwoven without clear boundaries. | Avoid when the concepts are merely numerous but well ordered, when a specific contradiction should be named, or when the phrase would sound too informal for the target register. |
+| ko | 문제는 간단해진다 | the problem becomes much easier to handle | Use for writing advice, technical explanations, debugging notes, process cleanup, or review comments where splitting a large sentence, task, issue, or procedure into smaller units makes it more tractable. | Avoid when the split hides a shared cause, when the units remain tightly coupled, or when the problem is hard because of missing evidence rather than size. |
+| ko | 일관성 없이 뚝뚝 끊어지는 | choppy and disconnected | Use for draft feedback, documentation review, UX copy, explanations, or presentation notes where short pieces exist but the rhythm or connective tissue has broken down. | Avoid when a terse, staccato style is intentional, when the issue is factual incompleteness, or when a more formal register should name the exact transition gap. |
+| ko | 조화롭게 섞어서 이어나갈 수 있어야 한다 | mix ___ and ___ in a balanced way | Use for prose, documentation, answer style, evidence presentation, technical explanation, or design notes where two modes such as short and long, concrete and abstract, or direct and contextual need deliberate balance. | Avoid when one side should clearly dominate, when balance would dilute a necessary emphasis, or when the two elements conflict rather than complement each other. |
+| ko | 부족하거나 넘치지 않게 | use ___ without underdoing or overdoing it | Use for emphasis, explanation, examples, abstraction, validation, automation, process design, or review guidance where both too little and too much would weaken the result. | Avoid when a hard threshold, exact rule, or explicit limit should be stated instead of a balance judgment. |
+| ko | 기본이 취약했다 | the foundation for ___ was weak | Use for system reviews, market analysis, team capability notes, test coverage, documentation, operations, or platform critiques where a weakness comes from the underlying base rather than one isolated mistake. | Avoid when the issue is a single defect, when the foundation is sound, or when a concrete missing support should be named directly. |
+| ko | 단박에 눈길을 사로잡는다 | immediately draws the reader's attention | Use for headings, warnings, release notes, issue summaries, documentation leads, UX copy, or report highlights where a compact line needs to focus the reader quickly. | Avoid when the goal is quiet background context, when attention-grabbing wording would feel promotional, or when evidence should matter more than rhetorical force. |
+| ko | 한창 진화 중 | ___ is still very much evolving | Use for products, ecosystems, codebases, markets, team processes, documentation systems, or standards that are active, changing, and not yet settled into a stable form. | Avoid when the subject is mature, frozen, formally specified, or when instability should be described as risk rather than evolution. |
+| ko | 완전히 새로운 개념으로 정립됐다 | was redefined as an entirely new concept | Use for terminology shifts, product categories, technical concepts, market framing, policy language, or documentation history where the meaning has changed, not merely the label. | Avoid when only the name changed, when the old meaning still applies, or when a formal definition should be quoted directly. |
+| ko | 범위 또한 폭발적으로 확장됐다 | the scope of ___ expanded dramatically | Use for feature scope, market size, user groups, responsibility boundaries, problem spaces, or review surfaces that have grown far beyond their earlier limits. | Avoid when growth is modest, unverified, or best expressed with exact numbers instead of broad language. |
+| ko | ___는 단지 양념에 지나지 않는다 | ___ is only seasoning, not the main structure | Use for product analysis, architecture reviews, document critique, feature planning, or explanation cleanup where an element adds flavor but does not carry the core structure. | Avoid when the element is actually required for correctness, safety, accessibility, or the main user value. |
+| ko | 주객전도 | the means has become the end | Use for project reviews, metric design, automation, testing, education, process critique, or product strategy where a tool, indicator, credential, or intermediate step has displaced the original purpose. | Avoid when the intermediate goal is legitimately the final objective, or when the reversed priority should be explained with concrete incentives instead of a compact phrase. |
+| ko | 단순히 흥미에 그치지 않고 | does not stop at surface interest | Use for examples, features, ideas, hooks, research findings, or design choices that first attract attention but also serve a deeper structural or explanatory role. | Avoid when the element is only decorative, when the deeper role has not been shown, or when a plainer functional statement would be clearer. |
+| ko | 익숙한 듯 새로운 것 | something familiar yet new | Use for product improvements, design updates, documentation style, refactors, narrative framing, or user experiences that should feel approachable while still offering novelty. | Avoid when the work is either fully conventional or intentionally radical, or when the phrase would blur a specific mechanism of novelty. |
+| ko | 속사정을 들여다보면 | once you look beneath the surface | Use for reviews, postmortems, product analysis, organizational notes, or explanatory writing where the visible story differs from the internal dynamics. | Avoid when no deeper inspection has happened, or when the phrase would imply hidden problems without evidence. |
+| ko | 편의상 ___지만 실제와 다르다 | for convenience, ___, but it does not match the reality | Use for documentation, reviews, translation notes, data modeling, examples, or explanatory writing where a convenient simplification helps the reader but must not be mistaken for the underlying truth. | Avoid when the simplification is fully accurate, when the difference is irrelevant, or when a formal model/implementation contract should be stated directly. |
+| ko | 가장 간명한 것 하나를 고른다면 | if one had to choose the most concise formulation | Use for reports, reviews, summaries, critiques, decision records, or explanatory answers where many possible descriptions exist but one compact formulation should anchor the discussion. | Avoid when the issue cannot be fairly compressed, when multiple formulations must be preserved, or when the chosen line is not actually representative. |
+| ko | 확인해두어야 할 것은 ___라는 점이다 | what should be made clear is that ___ | Use for documentation, issue summaries, review comments, policy notes, or analysis where a premise, caveat, or boundary must be established before the rest of the explanation can be read correctly. | Avoid when the point is already obvious, when it should be presented as evidence rather than framing, or when the phrase would over-formalize a simple note. |
+| ko | 그 과정을 짚어보려 한다 | trace how that process unfolded | Use for reports, incident analysis, change histories, technical explanations, retrospectives, or research notes where the reader needs to follow the development of a situation rather than only see the final state. | Avoid when sequence does not matter, when a concise result-first answer is enough, or when the process is still too uncertain to reconstruct. |
+| ko | 깊이와 천착에 이르지 못했다 | never quite reached depth or sustained inquiry | Use for reviews, self-assessments, research notes, documentation critiques, or postmortems where the work covered ground but did not investigate the subject deeply enough. | Avoid when the work was intentionally shallow, when the limitation is missing evidence rather than depth, or when a more specific deficiency should be named. |
+| ko | ___만으로는 더 이상 ___하기 어렵게 되었다 | ___ alone can no longer sustain ___ | Use for strategy reports, architecture reviews, roadmap notes, operational analysis, or policy writing where an approach that once worked no longer carries the next stage by itself. | Avoid when the old approach is still sufficient, when the claim needs quantitative proof, or when the real issue is execution rather than the model's limits. |
+| ko | 깊이 있는 분석을 수행하지 않은 상태에서 시도되고 있다 | is being attempted without a sufficiently deep analysis of ___ | Use for planning reviews, policy critiques, product strategy, design reviews, or implementation risk notes where action is moving ahead before the underlying group, system, market, or problem has been understood. | Avoid when the analysis already exists, when urgency justifies a bounded experiment, or when a concrete missing analysis should be named instead. |
+| ko | ___에 대한 이해가 선행될 필요가 있다 | a deeper understanding of ___ needs to come first | Use for research plans, issue summaries, technical design, discovery work, or policy notes where the next responsible step is to understand the subject before prescribing a solution. | Avoid when enough understanding already exists, when immediate containment is required, or when the phrase would delay an obvious fix. |
+| ko | 중요한 밑거름이 되었다 | provided an important foundation for ___ | Use for reports, retrospectives, policy notes, architecture histories, or ecosystem analysis where an earlier condition, institution, practice, or investment made later growth possible. | Avoid when the contribution was incidental, when the later outcome is not connected, or when a more concrete cause should be named instead. |
+| ko | 한 걸음 더 나아갔다 | took the next step toward ___ | Use for reports, update notes, project histories, implementation summaries, or strategy writing where prior support, evidence, or preparation has made a more concrete next step possible. | Avoid when there was no prior foundation, when the move was merely routine, or when the next step should be named as a discrete action instead. |
+| ko | 단순히 ___ 차원에서 벗어나 / 단순한 ___ 수준을 넘어서 | moved beyond merely ___ / moved beyond the level of mere ___ | Use for technical explanations, product strategy, architecture reviews, policy notes, or release summaries where work moves past a surface-level activity into a more structural, operational, or institutional layer. | Avoid when the change remains superficial, when the original layer is still the whole scope, or when the sentence should state the exact new layer directly. |
+| ko | 이러한 공백을 메워보려는 의도 아래 | with the aim of filling this gap | Use for reports, documentation introductions, research plans, pull request descriptions, or improvement proposals where the work is justified by a clear missing explanation, coverage area, workflow, or evidence surface. | Avoid when no specific gap has been shown, when the work is exploratory rather than gap-filling, or when the gap should be stated more directly. |
+| ko | 더 넓은 맥락에 ___을 포함시킬 수 있게 되었다 | place ___ within a broader context | Use for reports, analysis, technical documentation, reviews, or explanatory writing where a specific phenomenon needs to be positioned inside a larger structure, trend, or system. | Avoid when the broader context has not been established, when the local detail is enough, or when the phrase would make a narrow point sound overgeneralized. |
+| ko | 다른 차원에서 이해할 수 있지 않을까 | can be understood on a different level | Use for technical explanations, reviews, analysis, architecture notes, or essays where the same issue should be reframed at another layer of abstraction, system boundary, or explanatory level. | Avoid when the original level already answers the question, when the new level is speculative, or when abstraction would blur a concrete defect. |
+| ko | 사태의 핵심에 대한 이해는 ___처럼 쉬울 수 있다 | the core of the situation can be surprisingly simple | Use for technical explanations, incident summaries, teaching material, policy analysis, or system modeling where the details are complex but the central mechanism can be stated plainly. | Avoid when the simplified core has not been verified, when the details materially change the conclusion, or when the phrase would excuse shallow analysis. |
+| ko | 현실이 위에서 살펴본 사례와 유사하기 때문이다 | the real case follows the same pattern | Use for technical explanations, policy analysis, incident writeups, examples, reproductions, or user-behavior analysis where a concrete case maps onto a pattern already explained. | Avoid when the analogy is loose, when the real case has materially different mechanics, or when the connection should be proven rather than asserted. |
+| ko | 추상적인 진술에서 벗어나 생생하고 구체적인 모습을 띠게 | move beyond abstract statements into something concrete | Use for documentation, reviews, reports, explanations, issue writeups, or design notes where broad principles need to be grounded in examples, evidence, UI states, code paths, or operational steps. | Avoid when the abstract statement is intentionally normative, when concrete evidence is unavailable, or when examples would distract from a concise rule. |
+| en | the business at hand | return to the business at hand | Use for meeting notes, reviews, incident updates, long explanations, or document transitions where the writer needs to steer attention back to the concrete matter being handled. | Avoid when the apparent digression is necessary context, or when the phrase would sound dismissive of a stakeholder concern. |
+| en | looked out of place | ___ looked out of place in ___ | Use for UI reviews, document structure, feature placement, team roles, tone mismatches, or visual critique where something feels mismatched without needing to call it broken. | Avoid when the issue is a concrete defect, accessibility failure, or functional error that should be named directly. |
+| en | crystal clear | make sure we are crystal clear on ___ | Use to lock down definitions, assumptions, ownership, scope, or risk before moving into recommendations or decisions. | Avoid when the tone should stay understated, or when the point is already obvious and repeating it would sound patronizing. |
+| en | It would help a lot if you'd be just a little more specific | it would help if ___ were a little more specific | Use for review comments, requirements clarification, bug reports, planning notes, or feedback where the next step needs sharper detail without making the request sound hostile. | Avoid when the missing information is mandatory and should be requested directly, or when the vague wording is a blocker that needs a firm correction. |
+| en | one at a time | take ___ one at a time | Use for triage, reviews, migrations, question handling, support replies, or complex problem-solving where the work should be decomposed into manageable steps. | Avoid when the items are tightly coupled, when parallel handling is required, or when sequencing would hide a systemic issue. |
+| ko | 서로 맞물려 있다 | ___ and ___ are tightly interlocked | Use for cause analysis, systems explanations, bug root causes, organizational issues, policy effects, or product behavior where two forces cannot be understood in isolation. | Avoid when the relationship is merely sequential, when one side clearly dominates, or when a specific causal mechanism should be named directly. |
+| ko | 서로 분리될 수 없다 | ___ cannot be separated from one another | Use for requirements and implementation, policy and incentives, product and operations, data and interpretation, or any paired concerns whose meaning changes when separated. | Avoid when the relationship is loose, when separation is useful for analysis, or when independence is a formal requirement. |
+| ko | 남는 것은 오직 ___뿐이다 | what remains is only ___ | Use for postmortems, reviews, failed strategies, missing-context critiques, or explanations where removing the claimed substance reveals the narrow residue left behind. | Avoid when the remainder is still valuable, when the conclusion needs softer wording, or when the remaining elements should be itemized instead. |
+| ko | 하나씩 면밀히 따져보다 | examine each one carefully, one by one | Use for checklists, root-cause analysis, refactor plans, policy reviews, design critiques, or complex investigations where the responsible move is patient decomposition. | Avoid when a fast triage pass is enough, when items are tightly coupled, or when a single systemic cause should be addressed first. |
+| en | let's stop right there | let's stop right there and ask ___ | Use when pausing a narrative, review, or argument to challenge a premise before the reader accepts the next step. | Avoid when the text needs diplomacy, uninterrupted flow, or a gentler transition. |
+| en | good try, but unconvincing | a good try, but not yet convincing | Use for code review, proposal review, design critique, draft feedback, or analysis where the attempt has merit but the evidence, structure, or execution does not yet persuade. | Avoid when the work has no real merit, when a gentler phrase is needed, or when concrete reasons for the weak point are not provided. |
+| en | not the occasion to ___ | this is not the occasion to ___ | Use for meetings, reviews, incidents, public replies, or decision notes where an action or argument may be valid but the current setting is wrong for it. | Avoid when the real issue is that the action is wrong, not merely mistimed or misplaced. |
+| en | no purpose could be served by ___ | no purpose would be served by ___ | Use for reviews, retrospectives, disputes, or decision notes where further argument, explanation, or repetition would not improve the outcome. | Avoid when withholding explanation would reduce accountability, hide evidence, or leave stakeholders unable to act. |
+| en | the occasion calls for it | the occasion calls for ___ | Use for announcements, releases, incidents, ceremonies, or decision notes where the context justifies a stronger, more formal, or more deliberate action than usual. | Avoid when the action is merely decorative, disproportionate, or not actually required by the situation. |
+| en | least I could do | it was the least ___ could do | Use for apologies, remediation notes, thank-you replies, customer support, or follow-up actions where a limited gesture is still morally or professionally expected. | Avoid when the action is sufficient to resolve the whole issue, when stronger compensation is required, or when the phrase would minimize harm. |
+| en | take it to heart | take ___ to heart | Use for feedback, warnings, reviews, user complaints, or retrospective lessons that should be genuinely absorbed and reflected in later behavior. | Avoid when the point was merely acknowledged, when no change is expected, or when the phrase would overstate emotional sincerity. |
+| en | There is another factor | there is another factor: ___ | Use for reports, analysis, issue comments, design notes, or decision records where a new variable needs to be introduced without derailing the main argument. | Avoid when the factor is actually the main point, when the transition hides uncertainty, or when a stronger causal link should be stated directly. |
+| en | change of plan | change of plan: ___ | Use for incident updates, deployment pivots, schedule changes, investigation reroutes, or operational messages where a direction change should be stated cleanly and without excess ceremony. | Avoid when the change needs formal approval language, when the reason must be explained first, or when the phrase would make a major reversal sound too casual. |
+| ko | 한번쯤 곱씹어 생각해볼 필요가 있다 | worth pausing to think through at least once | Use for reviews, retrospectives, decision notes, security or operations checklists, or explanatory writing where a point should not be rushed past even if it seems familiar. | Avoid when the decision is urgent, when the issue is already settled, or when the phrase would soften a mandatory requirement. |
+| ko | ___의 판단에 맡기는 | leave ___ for the reader to judge | Use for reports, reviews, essays, technical explanations, or critique where the evidence is presented clearly but the writer deliberately avoids forcing the final interpretation. | Avoid when the conclusion is mandatory, safety-critical, already proven, or when withholding judgment would make the writing evasive. |
+| ko | 의문은 일단 접어 두고 | set that question aside for the moment | Use for analysis, reports, reviews, decision notes, or explanatory writing where a valid question should be temporarily deferred so the next premise, consequence, or structural issue can be examined. | Avoid when the deferred question is a blocker, when it is being dodged rather than sequenced, or when the answer must come before the next claim. |
+| ko | 굳이 ___하지 않아도 된다 | there is no need to ___ | Use for reviews, documentation edits, UI copy, refactors, or explanations where a repeated wrapper, emphasis, process step, or clarifying phrase can be removed without losing meaning. | Avoid when the omitted detail carries legal, safety, accessibility, evidence, or compatibility meaning, or when brevity would make the text less clear. |
+| ko | 다음처럼 바꾸면 더 좋겠다 | it would be better stated as ___ | Use for review comments, documentation edits, issue replies, or draft feedback where the useful move is to offer a cleaner replacement rather than only naming the flaw. | Avoid when the proposed wording changes the facts, softens a required warning, or when the defect needs a direct blocking comment. |
+| ko | 원점에서 재검토됐다 | was reconsidered from the ground up | Use for decision records, architecture changes, policy revisions, product direction, or postmortems where the original premise was reopened rather than merely adjusted. | Avoid when the change was a minor tweak, a routine retry, or when the original premise remained intact. |
+| ko | 군더더기다 | is excess weight | Use for prose, UI copy, documentation, API shape, code review, or process critique where an element adds bulk without adding meaning, safety, or utility. | Avoid when the extra material provides accessibility, evidence, auditability, backwards compatibility, or necessary context. |
+| ko | 여기서 끝이 아니다 | that is not where the work ends | Use for reviews, refactors, documentation, deployments, testing, releases, or iterative writing where one visible milestone is complete but the responsible follow-through still remains. | Avoid when the work is genuinely complete, when the follow-up is speculative, or when a concrete remaining action should be named directly. |
+
+## Assumption and Boundary Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| en | for the sake of argument | for the sake of argument, assume ___ | Use for design review, tradeoff analysis, debate, or research notes where a temporary assumption is being made without treating it as proven. | Avoid when the assumption is already established, or when the phrase would make a firm requirement sound optional. |
+| ko | 가능성을 열어 놓는 일 | keep open the possibility that ___ | Use for analysis, investigations, reviews, risk notes, interpretation, or design discussion where a plausible alternative, exception, or latent risk should remain visible until evidence closes it. | Avoid when the conclusion is already settled, when action requires a firm decision, or when the phrase would keep weak possibilities alive indefinitely. |
+| ko | 매개 변수의 문제뿐 아니라 원리의 문제 | not merely a matter of parameters, but of first principles | Use for architecture debates, security models, policy design, framework choices, or technical philosophy where the disagreement is about the governing premise rather than tunable values or implementation details. | Avoid when the issue really is a threshold, configuration, scale, or parameter choice, or when invoking first principles would make a practical fix sound grandiose. |
+| ko | 어느 하나에 결부되는 것이 아니라 그 둘을 모두 아우를 수 있는 | not tied to either one, but able to hold both together | Use for design explanations, tradeoff analysis, policy notes, reviews, or conceptual framing where a useful idea should not be reduced to one side of a pair because its value comes from holding both forces, constraints, or perspectives together. | Avoid when the two sides are actually incompatible, when one side should be rejected, or when the phrase would blur a necessary decision. |
+| ko | 건너뛰어서는 안 될 부분을 분명히 해야겠다는 | make explicit the part that must not be skipped | Use for design reviews, migrations, authorization flows, testing, incident procedures, skill instructions, or operational checklists where an omitted step would weaken safety, correctness, or accountability. | Avoid when the step is optional, when the sequence can safely vary, or when the missing part should be encoded as a hard requirement instead of prose guidance. |
+| ko | 단순히 ___라고 생각했었는데 | I had assumed it was simply ___ | Use for debugging, design review, analysis, reports, or postmortems where an initial shallow assumption is being corrected by later evidence or context. | Avoid when the assumption was already evidence-backed, when the correction is speculative, or when first-person framing does not fit the register. |
+| ko | 힘들이지 않고 저절로 | without effort, almost automatically | Use for UX analysis, habit formation, intuition, automation, background system behavior, or cognitive explanations where something happens with little visible effort or conscious control. | Avoid when the action requires deliberate work, when effort is central to the point, or when a precise automation mechanism should be named instead. |
+| ko | 우리도 모르는 방식으로 | in ways we do not notice | Use for UX, security, automation, habits, organizational culture, cognitive bias, or product behavior where an influence is real but not visible to the person affected. | Avoid when the effect is directly observable, when the actor is consciously choosing it, or when a precise mechanism should be named. |
+| ko | ___에 우선순위를 두도록 설계되었다 | is wired to prioritize ___ | Use for UX, security, operations, organizational behavior, automation, or system explanations where a default tendency or structural response favors one class of signal over another. | Avoid when no design, incentive, habit, or built-in tendency has been shown, or when the phrase would overstate an accidental behavior as intentional design. |
+| en | put it down to ___ | we put it down to ___ | Use for early diagnosis, user-feedback interpretation, incident analysis, retrospectives, or decision records where an initial explanation was plausible but still provisional. | Avoid when the cause is already proven, when the explanation was never evidence-backed, or when the phrase would hide the need for further investigation. |
+| en | as far as I know | as far as we know, ___ | Use to qualify a statement, report, review, or support answer when the available evidence is bounded and new information could change the conclusion. | Avoid when the fact has been verified, when a firmer source is required, or when the phrase would hide missing evidence. |
+| en | I can't be sure, but ___ | I cannot be sure, but ___ | Use for investigations, code reviews, incident notes, reports, or risk calls where a claim is plausible from available evidence but still needs a visible confidence boundary. | Avoid when certainty is required, when the claim is unsupported, or when a direct "unknown" would be more honest. |
+| ko | 주저 없이 단정했다 | concluded without hesitation | Use for retrospectives, review notes, external-feedback triage, decision analysis, or critique where the speed and confidence of a conclusion are themselves part of the risk. | Avoid when the conclusion was properly verified, when decisiveness is the point, or when a direct finding should be stated without implying recklessness. |
+| en | all bets were off | all bets are off if ___ | Use for contracts, trust boundaries, security assumptions, collaboration rules, policy notes, or risk reviews where one violated condition invalidates the previous agreement or premise. | Avoid when the condition only changes priority, when the agreement remains partly valid, or when the phrase would sound too absolute for a negotiable situation. |
+| en | we have to draw the line somewhere | we have to draw the line somewhere | Use for policy, authorization, scope, review, or product decisions where unlimited expansion is not acceptable and a boundary must be named. | Avoid when the boundary is arbitrary, punitive, or not backed by a clear criterion. |
+| ko | 할 수 있는 일과 할 수 없는 일 그리고 해서는 안 될 일 | what ___ can do, what ___ cannot do, and what ___ must not do | Use for policy, tool design, agent behavior, platform scope, team ownership, architecture, or operational guidance where the useful boundary includes capability, limitation, and prohibition. | Avoid when a simpler allow/deny rule is enough, when the forbidden category has not been justified, or when the wording would make ordinary tradeoffs sound moralized. |
+| ko | 경계선을 쉽게 그어 준다 | makes the boundary easier to draw | Use for rules, review criteria, policy distinctions, security boundaries, quality standards, or technical explanations where new evidence or a clearer framing makes an otherwise ambiguous distinction easier to make. | Avoid when the boundary remains contested, when the line is arbitrary, or when the phrase would imply more clarity than the evidence supports. |
+| ko | 자유는 침해하지 않으면서 그런 도움을 줄 방법 | offer help without taking away agency | Use for UX, policy, onboarding, automation, safety design, or permission flows where the goal is to guide people toward a better choice without removing meaningful choice. | Avoid when a hard control is required, when the help is actually coercive, or when the user has no real path to opt out. |
+| en | paled into insignificance | ___ paled into insignificance beside ___ | Use for priority comparisons, risk assessment, incident severity, tradeoff analysis, or narrative explanations where one concern becomes minor when compared with a much larger concern. | Avoid when the contrast is mild, when both concerns still need equal attention, or when the phrase would dismiss a stakeholder's real problem. |
+| en | put ___ at risk | this puts ___ at risk | Use for security, privacy, deployments, operations, user experience, or dependency reviews where a choice creates concrete exposure for a person, system, team, or outcome. | Avoid when the risk is only theoretical, already mitigated, or better described as inconvenience, cost, or uncertainty. |
+| ko | 안정된 ___을 위태롭게 하는 | threatens the stable ___ | Use for operations, trust, mental models, system state, team rhythm, or explanatory writing where an event or change disrupts a previously settled condition. | Avoid when the baseline was never stable, when the disruption is only aesthetic, or when a precise failure mode should be named directly. |
+| ko | ___보다 특별히 취급되며, 마땅히 그래야 한다 | is treated as exceptional, and rightly so | Use for security risks, safety concerns, privacy exposure, regulatory constraints, operational incidents, or high-consequence edge cases that deserve a stricter path than ordinary cases. | Avoid when the special treatment is not justified, when the exception is merely preference, or when the reason needs to be stated with a concrete policy instead. |
+| en | the only defense | the only defense against ___ | Use for security controls, tests, reviews, backups, approvals, validation gates, or operational safeguards where one mechanism is the last meaningful protection against a known failure mode. | Avoid when there are multiple independent safeguards, when the protection is unproven, or when the phrase would overstate a convenience as a safety boundary. |
+| en | take too much upon yourself | ___ may be taking too much upon itself | Use for module responsibility, team roles, admin privileges, automation scope, ownership boundaries, or review notes where one actor or component is absorbing more responsibility than it should. | Avoid when the responsibility is explicitly assigned, intentionally centralized, or backed by clear ownership and safeguards. |
+| en | everything has its breaking strain | everything has its breaking strain | Use for operational load, team fatigue, system limits, long-running risk, or process pressure where the point is that no person, system, or practice can absorb stress indefinitely. | Avoid when there is no evidence of accumulating strain, when a measured limit should be stated instead, or when the phrase would dramatize a minor inconvenience. |
+| ko | 상대에 따라 다릅니다 | it depends on who or what you are dealing with | Use for security, operations, negotiation, API policy, reviews, or process design where a universal rule would flatten materially different cases. | Avoid when the context is known enough to choose a direct rule, or when "it depends" would dodge a decision. |
+| en | not to everyone's taste | ___ is not to everyone's taste | Use for UI choices, writing style, technical preferences, workflow policy, or product direction where disagreement is mostly about taste, fit, or audience rather than correctness. | Avoid when the issue is a real defect, safety concern, accessibility problem, or measurable failure. |
+| en | held no appeal | ___ holds little appeal for ___ | Use for proposals, product directions, implementation options, or stylistic choices that are valid but not attractive for the current audience or goal. | Avoid when the option is objectively wrong, unsafe, or impossible; name the concrete defect instead. |
+| en | to the letter | follow ___ to the letter | Use for procedures, policies, security rules, compliance steps, runbooks, or test instructions that must be followed exactly. | Avoid when adaptive judgment is required, when the instructions are incomplete, or when literal compliance would violate the intent. |
+| ko | 딱 좋을 정도로 안정된 | stable enough to feel ___ | Use for operations, schedules, product quality, team rhythms, relationships, or prose tone where the point is not perfection but a sufficient sense of settled balance. | Avoid when stability has not been observed, when formal reliability evidence is required, or when "feel" would weaken a measured claim. |
+| ko | ___가 되는 것은 아니다 | that alone does not make ___ a ___ | Use for classification, role boundaries, technology choices, reviews, policy arguments, or conceptual distinctions where one shared trait is not enough to place something in a stronger category. | Avoid when the category is formally defined by that trait, when the distinction is obvious, or when a direct definition would be clearer. |
+
+## Verification and Evidence Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| en | something was amiss | something was amiss with ___ | Use for incident reports, code reviews, operational notes, product analysis, or narrative setup where a problem is sensed before the cause is identified. | Avoid when the issue is already diagnosed, or when the phrase would replace concrete evidence with vague unease. |
+| ko | 무엇이 잘못됐는지 콕 집어내기 어려운 문제 | hard to pinpoint exactly what is wrong | Use for UI reviews, writing feedback, design critique, UX analysis, performance triage, incident investigation, or code review where something is visibly off but the exact fault has not yet been isolated. | Avoid after the cause has been identified, when the issue can be named directly, or when the phrase would let a vague impression stand in for evidence. |
+| en | something had gone wrong just the same | something had gone wrong just the same | Use for incident reports, debugging notes, deployment reviews, tests, or data-quality analysis where the exact cause is not yet known but the presence of a real failure is no longer in doubt. | Avoid when the evidence only suggests unease, when the failure has already been precisely diagnosed, or when a concrete error name should be used instead. |
+| en | possibility is faint | the possibility is faint, but ___ | Use for risk analysis, investigations, incident notes, or research where a scenario is unlikely but still worth naming or checking. | Avoid when the possibility is already disproven, when action depends on a stronger likelihood threshold, or when the phrase would keep a dead lead alive. |
+| en | to the extent ___ could | ___, to the extent the available evidence allows | Use for investigations, audits, incident reports, security reviews, or research summaries where the analysis should be explicit about the limits of available evidence. | Avoid when the evidence is complete, when a firm requirement must be stated, or when the phrase would soften an already-proven finding. |
+| ko | 아직 너무 일러서 확실하게 말할 수는 없지만 | it is still too early to say with confidence, but ___ | Use for analysis reports, release observations, performance changes, market or user reactions, and post-incident follow-up where an early signal is visible but the conclusion should remain provisional. | Avoid when enough evidence already supports a firm conclusion, when action cannot wait for confidence, or when the phrase would soften a known risk. |
+| ko | 이렇다 할 물증도 없는 상태 | with no concrete evidence to point to | Use for investigations, audits, incident reports, security reviews, or bug analysis where a claim remains plausible but lacks direct supporting proof. | Avoid when indirect evidence is strong enough to state a finding, or when "no concrete evidence" would erase known signals. |
+| ko | 살펴볼 경황이 없었습니다 | there was no room to properly inspect ___ | Use for incident response, urgent debugging, support triage, reviews, or postmortems where pressure, interruption, or confusion prevented a careful check. | Avoid when the missed inspection was required, negligent, or should be named as a process failure. |
+| ko | 눈속임입니다 | it was misdirection | Use for investigations, debugging, security reviews, UX analysis, or incident reports where the obvious signal points away from the actual cause or mechanism. | Avoid when the misleading effect is accidental, unproven, or better described as ambiguity rather than misdirection. |
+| ko | 단순한 확인 작업 | a routine confirmation check | Use for QA, debugging, reviews, audits, investigations, or support replies where a step verifies a fact without implying a blocker or accusation. | Avoid when the check is high-risk, decisive, or expected to change the plan. |
+| ko | 신원확인 더 철저히 하셔야겠습니다 | ___ needs a stricter verification step | Use for identity checks, auth, permission reviews, deployment approvals, operational handoffs, or process controls where trust must be backed by a stronger check. | Avoid when the current verification is already sufficient, or when adding friction would not reduce real risk. |
+| ko | 뒷받침이 될 만한 증거를 확보할 수 있는 부분은 모조리 | every place where supporting evidence can be secured | Use for audits, incident reports, investigations, test plans, or review notes where all available evidence surfaces should be captured. | Avoid when the scope is intentionally sampled, time-boxed, privacy-limited, or too broad to inspect safely. |
+| ko | 먼저 사실을 직시할 필요가 있다 | first, the facts have to be faced | Use for reports, reviews, policy debates, incident retrospectives, external-feedback triage, or corrective writing where interpretation must wait until uncomfortable evidence is acknowledged. | Avoid when the facts are already accepted, when the wording would sound scolding, or when the next step should be a concrete finding rather than a rhetorical reset. |
+| ko | 사실에 정면으로 모순되는 | flatly contradicts the facts | Use for reviews, rebuttals, external-feedback triage, reports, policy analysis, benchmark analysis, or issue comments where a claim directly conflicts with established evidence. | Avoid when the evidence is incomplete, when the conflict is only interpretive, or when a softer confidence boundary is needed. |
+| ko | 차고 넘쳤다 | was more than abundant | Use for evidence, logs, counterexamples, failure cases, user feedback, or observed signals where the quantity is enough to make avoidance or denial difficult. | Avoid when the evidence is merely sufficient, when quantity is not the issue, or when the writing should name the decisive evidence instead. |
+| ko | 요행의 결과였다고 할 수 있다 | owed more to luck than to design | Use for retrospectives, reliability reviews, operational successes, policy outcomes, releases, or system stability notes where a good result appears to depend more on favorable conditions than on deliberate design. | Avoid when the design contribution has been verified, when the success was intentionally engineered, or when the phrase would dismiss real skill or preparation. |
+| ko | 세세한 점에서 크게 참고가 되는 부분 | details that proved materially useful | Use for reviews, investigations, design notes, debugging, or document analysis where small details meaningfully inform the conclusion. | Avoid when the details are merely decorative, incidental, or not actually used in the decision. |
+| ko | 정곡을 찌르는 바가 있다 | strikes at the heart of the matter | Use for feedback, advice, review comments, logs, evidence, examples, or observations that pinpoint the central issue rather than a peripheral symptom. | Avoid when the point is only partially relevant, when the evidence is not decisive, or when the phrase would overstate an interesting observation as the core truth. |
+| ko | 놀랍도록 다양한 사례에서 | across a surprisingly wide range of cases | Use for research summaries, bug patterns, operational examples, user behavior, policy effects, or technical analysis where one principle appears across more contexts than expected. | Avoid when the cases are few, cherry-picked, or too similar, or when a quantified scope would be more precise. |
+| ko | 관련 있는 요소를 가려내는 | separate what actually matters from what merely feels salient | Use for reviews, policy analysis, decision records, incident analysis, product decisions, or research summaries where the writer needs to distinguish real decision criteria from vivid but irrelevant signals. | Avoid when salience is itself the thing being measured, when the distinction has not been justified, or when the phrase would dismiss a legitimate concern. |
+| ko | ___의 좋은 지표는 못 된다 | is not a reliable measure of ___ | Use for reports, performance analysis, code reviews, quality evaluation, research summaries, or operational notes where a visible count, surface signal, or convenient metric does not faithfully represent the underlying reality. | Avoid when the metric is validated for the target claim, when a precise statistical limitation should be named, or when the phrase would dismiss useful proxy evidence too broadly. |
+| ko | 명백히 ___한 흔적 | clear signs of ___ | Use for audits, forensics, QA, bug analysis, incident reports, security review, or evidence-based prose where visible observations support a concrete condition. | Avoid when the signal is subtle, indirect, or ambiguous; use "telltale signs" or a qualified phrase instead. |
+| ko | 상황 증거에만 바탕을 둔 | based only on circumstantial evidence | Use for incident analysis, security review, debugging, audits, or claims where the evidence is indirect and the conclusion must stay qualified. | Avoid when direct proof exists, or when the phrase would make a well-supported conclusion sound weaker than it is. |
+| ko | 모두 내 추측에 지나지 않는다 | all of this is still only conjecture | Use for investigations, log analysis, security reviews, incident reports, or design debates where the current explanation must stay explicitly unproven. | Avoid when evidence is already direct enough to state a finding, or when the phrase would weaken a sufficiently supported conclusion. |
+| ko | 어떤 쪽으로든 해석할 수 있었다 | could be interpreted either way | Use for reviews, incident analysis, interviews, design debates, or log analysis where the evidence supports more than one plausible reading. | Avoid when the evidence clearly points in one direction or when ambiguity is being used to avoid a necessary decision. |
+| ko | 다른 방식으로 읽어야 할지도 모릅니다 | it may need to be read another way | Use for log analysis, document review, requirements analysis, data interpretation, debugging, or research when the same artifact may reveal a different meaning under another frame. | Avoid when there is no plausible alternate reading, or when the existing reading has already been verified by stronger evidence. |
+| ko | 반대의 해석도 성립될 텐데 | the opposite interpretation could also hold | Use when a log, requirement, metric, witness statement, or review finding can support an opposing conclusion and the analysis must stay cautious. | Avoid when the opposite reading is merely rhetorical, unsupported, or weaker than the primary interpretation. |
+| ko | 사실과 거짓이 섞여 있을 수도 있고요 | the signal may contain both truth and noise | Use for log analysis, user reports, external feedback, rumor review, AI answer review, or data-quality work where a source may be partially right but still contaminated by error or exaggeration. | Avoid when the source is wholly fabricated, fully verified, or when "noise" would dismiss meaningful stakeholder experience. |
+| ko | 나름대로 큰 참고가 되었다 | proved useful context in its own right | Use for investigation notes, retrospectives, design reviews, or research where information is not decisive but still meaningfully shapes the analysis. | Avoid when the information is irrelevant, merely interesting, or should not influence the conclusion. |
+| en | offered up | the reasons offered up for ___ | Use when naming stated justifications, explanations, or rationales while keeping room to evaluate whether they are actually sufficient. | Avoid when the reasons are verified causes, formal findings, or accepted requirements rather than claims being examined. |
+| ko | 놓친 통찰력 | the supposedly missed insight | Use for external feedback review, AI-answer verification, critique, postmortems, or argument analysis where a claim is framed as something everyone else missed and should be treated with cautious distance. | Avoid when the insight has already been validated, when the tone should be more neutral, or when the phrase would unfairly dismiss a real discovery. |
+| en | judge of the matter for herself / form your own opinion | let ___ form their own opinion / judge the matter for ___self | Use for investigations, reviews, audits, product checks, user tests, or decisions where someone should inspect the evidence or experience before being given a conclusion. | Avoid when independent judgment is unsafe, redundant, unauthorized, or when the available primary evidence has already been inspected. |
+| en | telltale signs | the telltale signs of ___ | Use for bugs, design debt, security smells, quality drift, or writing problems where small visible clues reveal a larger underlying condition. | Avoid when the evidence is speculative, invisible to the reader, or too weak to signal the broader issue. |
+| en | less room for mistakes | keep ___ close to the truth; less room for mistakes that way | Use for procedures, test data, cover stories, documentation, or operational handoffs where fidelity to reality reduces coordination errors. | Avoid when realism would expose sensitive data, violate privacy, or make a harmless abstraction unnecessarily concrete. |
+| en | came up as a match | ___ came up as a match for ___ | Use for search results, log correlation, audit findings, test diagnostics, detection workflows, or evidence matching. | Avoid when the match is fuzzy, unverified, or only a loose similarity rather than a meaningful result. |
+| en | hard to determine | it is hard to determine whether ___ | Use for analysis, risk review, incident investigation, external feedback review, or research where available evidence is insufficient or reactions point in different directions. | Avoid when the uncertainty comes from skipped investigation that should be performed first, or when a stronger source already answers the question. |
+| en | at first it looked like ___, but on closer inspection, ___ | at first it looked like ___, but on closer inspection, ___ | Use for debugging, audits, investigations, research notes, code review, or design critique where the first impression changes after closer evidence. | Avoid when there was no meaningful initial misread, or when "closer inspection" is not backed by actual inspection. |
+| en | I didn't know everything there was to know | we did not yet have the full picture | Use for investigations, reviews, postmortems, support analysis, or decision records where later evidence shows the earlier view was incomplete. | Avoid when the missing context was already available but ignored, or when a stronger accountability statement is needed. |
+| en | barely scratched the surface | barely scratched the surface of ___ | Use for reports, audits, reviews, investigations, research notes, or codebase orientation where the current pass found useful signals but has not inspected the full depth of the subject. | Avoid when the analysis is already comprehensive, when the scope was intentionally narrow and complete, or when the phrase would excuse skipped required checks. |
+| en | with grossly inadequate information | with grossly inadequate information | Use for decision records, risk reviews, incident reports, planning notes, or postmortems where a team had to decide or act despite a severe evidence gap. | Avoid when the information gap is mild, when better evidence was readily available but ignored, or when the wording would dramatize normal uncertainty. |
+| ko | ___을 반영할 방법도 없었다 | had no way to account for ___ | Use for analysis limits, evaluation models, forecasts, risk reviews, incident reports, or design critiques where an important factor exists but the method cannot represent it. | Avoid when the factor can be measured or modeled directly, when the omission is negligent, or when the method should be fixed rather than merely described. |
+| en | put two and two together | put two and two together | Use for investigations, log analysis, support triage, audits, or reviews where separate clues combine into a plausible conclusion. | Avoid when direct evidence already proves the point, or when the clues are too weak to support the inference. |
+| ko | 한 가닥만은 잡을 수 있었다 | could at least grasp one thread of ___ | Use for complex conversations, logs, requirements, incidents, or research notes where the full situation remains unclear but one useful strand can be followed. | Avoid when the evidence is already complete, or when the single strand is too weak to guide the next step. |
+| en | a new thread that he wanted to follow | a new thread worth following | Use for debugging, investigations, code review, research, or log analysis where a fresh lead emerges and deserves follow-up without claiming it is already decisive. | Avoid when the lead is speculative noise, when it distracts from a higher-priority path, or when the evidence is already strong enough to state a finding. |
+| en | something he could not quite place | something ___ could not quite place | Use for reviews, UX critique, incident triage, interviews, or narrative analysis where something feels off but has not yet been named or diagnosed. | Avoid when a concrete defect can already be identified, when the feeling is unsupported by any observation, or when vague unease would replace evidence. |
+| ko | 결정적으로 확신하게 된 건 ___ 때문이었다 | what made the conclusion decisive was ___ | Use for investigation reports, root-cause analysis, code reviews, audits, or decision records where one final piece of evidence turns a suspicion into a supported conclusion. | Avoid when the evidence is only suggestive, when certainty is overstated, or when multiple weak signals still need qualification. |
+| ko | 인정할 수밖에 없다 | there is little choice but to acknowledge ___ | Use for review findings, external-feedback triage, incident analysis, data interpretation, or technical critique where the evidence makes an uncomfortable conclusion hard to avoid. | Avoid when the evidence is still thin, when the conclusion is optional, or when a direct requirement or finding should be stated instead. |
+| en | the answer may well lie in ___ | the answer may well lie in ___ | Use for investigation plans, root-cause notes, review comments, or research where a likely evidence source or explanatory area is being named without overstating certainty. | Avoid when the answer is already known, when the lead is speculative, or when "may" would weaken a required action. |
+| en | all in readiness for ___ | all in readiness for ___ | Use for deployment, launch, meeting, review, handoff, event, or operations updates where the relevant preparation is complete and waiting for the next step. | Avoid when readiness is partial, unverified, blocked by approvals, or dependent on hidden prerequisites. |
+| en | kept in readiness for ___ | keep ___ in readiness for ___ | Use for deployment preparation, support coverage, on-call response, meeting materials, recovery plans, or operating environments that should remain prepared before they are needed. | Avoid when readiness has not been verified, when maintaining the standby state has hidden cost, or when the preparation should be created on demand instead. |
+| ko | 겉에서 보기에는 그럴싸했다 | it looked convincing from the outside | Use for architecture reviews, product analysis, postmortems, external feedback, or vendor/tool evaluations where the surface appears sound but the internal reality needs inspection. | Avoid when the external view is enough for the decision, or when the phrase would imply hidden defects without evidence. |
+| ko | 화려한 앞면 뒤에는 늘 ___이 있기 마련이었다 | behind the polished front, there was always ___ | Use for product critiques, operations reviews, organizational analysis, security reviews, or narrative explanations where a polished exterior hides a rougher internal reality. | Avoid when the contrast is not evidenced, or when the phrase would make an ordinary tradeoff sound deceptively sinister. |
+| en | the first small warning that ___ might not turn out to be ___ | the first small warning that ___ might not turn out to be ___ | Use for retrospectives, incident reports, code reviews, project updates, or product analysis where an early weak signal later proves meaningful. | Avoid when the warning was obvious, when hindsight is doing all the work, or when no later evidence showed the signal mattered. |
+| en | none of which were of any immediate help | none of which offered immediate help | Use for debugging, investigations, research notes, support analysis, or evidence reviews where many answers or findings exist but none yet unlock the next step. | Avoid when a finding was actually actionable, when the issue is lack of effort rather than lack of usefulness, or when the specific blockers should be named. |
+| en | Consider the sequence of events | consider the sequence of events | Use for incident analysis, debugging, investigative reports, audit notes, or retrospectives where the order of facts changes the interpretation. | Avoid when sequence is irrelevant, when causality has not been established, or when a summary-first explanation would be clearer. |
+| en | items which tell us more than he meant them to tell | ___ tells us more than it was meant to tell | Use for logs, diffs, comments, design traces, review evidence, or stakeholder statements that reveal useful information beyond their surface purpose. | Avoid when the signal is speculative, when private intent is being guessed too strongly, or when direct evidence should be cited instead. |
+| en | careful perusal could wait | a more careful review can wait | Use for incident response, first-pass audits, triage, release follow-ups, or investigations where immediate orientation matters more than exhaustive inspection. | Avoid when correctness depends on the detailed review now, when delay would create risk, or when the phrase would excuse skipping required due diligence. |
+| en | and more | everything expected was there, and more | Use for investigation summaries, log review, package inspection, codebase orientation, or evidence reports where the expected artifact is present along with additional relevant signal. | Avoid when the extra material is irrelevant, when the expected item is missing, or when the additional evidence should be itemized instead of summarized. |
+| en | finally got it | finally, the missing piece clicked into place | Use for debugging, root-cause analysis, retrospectives, investigations, or explanatory writing where scattered clues suddenly form a coherent explanation. | Avoid when the conclusion is still tentative, when no missing piece existed, or when a gradual analysis should be described more plainly. |
+| ko | 갭을 메웠다 | filled in the missing gap | Use for documentation updates, data analysis, test coverage, investigations, follow-up reviews, or design explanations where a missing link, missing evidence, or missing connective step has been supplied. | Avoid when the gap remains open, when the addition is only decorative, or when the missing piece should be named directly. |
+| en | a tantalising step closer | a tantalizing step closer to ___ | Use for progress updates, investigations, release work, debugging, research, or goal tracking where a new result is meaningful but still short of completion. | Avoid when the work is already finished, when the step is trivial, or when the phrase would overstate uncertain progress. |
+| ko | 단기적인 동요와 장기적인 추세를 구분해내는 | separate short-term fluctuations from the long-term trend | Use for metric analysis, performance reports, product growth, incident recovery, market interpretation, or operational reviews where temporary movement must be distinguished from durable direction. | Avoid when there is too little history to identify a trend, when the short-term movement is itself the incident, or when a statistical method should be stated instead. |
+
+## Decision and Exploration Fragments
+
+| Source Language | Source Fragment | Reusable English Pattern | Use Guidance | Avoid When |
+| --- | --- | --- | --- | --- |
+| ko | 가보지 않고서는 아무것도 알 수 없다 | nothing can be known without going there | Use for decisions, investigations, experiments, debugging, field checks, migrations, or relationships where direct entry or execution is the only honest way to reduce uncertainty. | Avoid when enough evidence already exists, or when the next step is unsafe, irreversible, or needs approval before exploration. |
+| ko | 끝까지 가보기 전엔 알 수 없는 일 | it cannot be known until ___ is seen through to the end | Use for experiments, releases, migrations, negotiations, investigations, or long-running plans where midstream judgment would be premature. | Avoid when earlier evidence is sufficient, when waiting would increase avoidable risk, or when the process has a safe early-stop criterion. |
+| ko | 가볍게 취할 수 있는 조치는 아니다 | not a step to be taken lightly | Use for migrations, releases, security changes, policy shifts, organizational decisions, or irreversible operations where the action is possible but deserves visible caution because of its blast radius. | Avoid when the step is routine, low-risk, easily reversible, or when a concrete approval or rollback requirement should be named instead. |
+| en | the temptation was too much to resist | the temptation to ___ was hard to resist | Use for design decisions, shortcuts, optimizations, releases, workarounds, or process choices where a flawed option still had an understandable pull. | Avoid when the choice was not actually tempting, when the option was plainly correct, or when the wording would excuse a preventable mistake. |
+| en | on a hunch | do not bet ___ on a hunch | Use for risk reviews, architecture decisions, operations planning, or strategy notes where a large commitment needs evidence rather than instinct alone. | Avoid when the choice is intentionally exploratory, low-cost, reversible, or explicitly framed as an experiment. |
+| en | given enough time | given enough time, ___ | Use for debugging, investigations, negotiations, recovery work, refactors, or research where a result may be achievable but depends on time or runway. | Avoid when time alone will not solve the problem, when resources or authority are the real constraint, or when the phrase would hide an urgent deadline. |
+| en | we'll improvise | the plan depends too much on improvisation | Use for deployment plans, operational readiness, security reviews, incident response, or project planning where flexibility is masking missing preparation. | Avoid when adaptation is an intentional, bounded part of the plan with clear guardrails and fallback paths. |
+| en | had no alternative but to ___ | there was no practical alternative but to ___ | Use for incident response, migrations, decision records, support explanations, or operational tradeoffs where the constraints left one viable path. | Avoid when the choice was merely preferred, when meaningful alternatives were skipped, or when the wording would excuse a preventable constraint. |
+| en | one of the most taxing days | one of the most taxing ___ | Use for demanding incidents, reviews, migrations, support cases, or project phases where the burden matters but should be stated with restraint. | Avoid when the difficulty was mild, purely emotional, or better measured with concrete duration, cost, or severity. |
+| en | I was at a loss / at a loss for an answer | ___ was at a loss for ___ | Use for incident notes, support replies, analysis, retrospectives, interviews, or communication reviews where someone genuinely lacks a clear answer, next step, or explanation at that moment. | Avoid when a clear answer existed, when the uncertainty came from skipped investigation, or when the phrase would hide poor preparation. |
+| en | satisfy your curiosity about ___ | satisfy curiosity about ___ | Use for research, experiments, product exploration, diagnostics, or stakeholder discovery where the goal is to answer an open question without overstating its urgency. | Avoid when the investigation is required for safety, compliance, correctness, or a blocking decision; use stronger language there. |
+| en | there is only one way to find out | there is only one way to find out | Use for experiments, deployments, rehearsals, investigations, tests, or operational checks where discussion has reached its limit and direct verification is the honest next step. | Avoid when safer evidence can answer the question first, or when the only way to find out would be reckless, irreversible, or approval-gated. |
+| en | begin with the relevant factor most easily checked | begin with the relevant factor most easily checked | Use for debugging, research, incident triage, audits, or design reviews where a tangled problem should be reduced by checking the simplest relevant fact first. | Avoid when the easiest check is not relevant, when a safety-critical path must be handled first, or when the phrase would hide a required broader investigation. |
+| ko | 어떤 대답도 정답이 아니며 | no single answer is the answer | Use for policy, architecture, product strategy, performance work, research, or design analysis where the question cannot be honestly closed by one universal answer and must remain open to context. | Avoid when a concrete answer is required, when the issue has a formal rule, or when the phrase would be used to avoid making a necessary decision. |
+| ko | 유일한 해답은 각각의 경우를 하나하나 따져보는 수밖에 없다는 것 | the only honest answer is to examine the cases one by one | Use for policy, security, architecture, performance, external-feedback review, technology choices, or case analysis where a universal formula would hide material differences and each case needs its own evidence. | Avoid when a general rule is already established, when cases are truly homogeneous, or when case-by-case review would be used to avoid setting a needed standard. |
+| en | I won't be satisfied until I see the situation for myself | do not be satisfied until ___ is seen directly | Use for code review, operational checks, incident analysis, user reproduction, field validation, or external-feedback review where secondhand claims should be replaced by direct evidence. | Avoid when direct inspection is impossible, unsafe, privacy-invasive, or unnecessary because stronger verified evidence already exists. |
+| en | I cannot tell you how useful ___ would be until I see it | we cannot tell how useful ___ will be until we inspect it | Use for codebase orientation, log review, data sampling, external feedback triage, audits, or research where the value of an artifact cannot be judged before direct inspection. | Avoid when the artifact is clearly irrelevant, when inspection is unauthorized or unsafe, or when the phrase would justify opening scope without a concrete reason. |
+| en | With infinite labour | after painstaking effort, ___ | Use for implementation notes, investigations, migrations, refactors, data cleanup, or research where the result matters partly because the path required careful, tedious, sustained work. | Avoid when the work was quick, routine, automated, or when emphasizing effort would distract from whether the result is correct. |
+| en | Still they were not what they sought | still, it was not what ___ had been looking for | Use for debugging, research, discovery, product validation, audits, or investigations where a finding is real or valuable but does not answer the original question. | Avoid when the discovery actually satisfies the goal, or when the wording would undervalue a useful adjacent finding. |
+| ko | 그것이 마치 ___처럼 어렵게 느껴졌다 | even a small next step felt disproportionately difficult | Use for UX analysis, onboarding notes, burnout discussions, workflow reviews, or support writing where a small action feels much harder because of fatigue, friction, fear, or context. | Avoid when the difficulty is objectively large, when measurable effort matters more than felt friction, or when the wording would over-psychologize the user. |
+| ko | 어디서부터 손을 대야 할지 알 수가 없었다 | it was not clear where to start | Use for legacy reviews, large refactors, incident response, data cleanup, research, or investigation notes where the problem is too broad or tangled for an obvious first step. | Avoid when a clear next action exists, or when the phrase would excuse delaying a necessary first check. |
+| en | I stand at the parting of the ways | stand at the parting of the ways | Use for decisions, strategy shifts, project inflection points, career notes, or risk calls where one choice will shape the path that follows. | Avoid when the decision is routine, reversible, or too small to justify a crossroads metaphor. |
+| en | while we still can | ___ while we still can | Use for rollbacks, exits, shutdowns, budget controls, risk containment, or remediation where the window to act is closing. | Avoid when the urgency is manufactured, or when the action can safely wait for more evidence. |
+| en | as long as it takes | for as long as it takes | Use for investigations, recovery work, migrations, refactors, negotiations, or support cases where the duration cannot be fixed upfront and the commitment is to finish properly. | Avoid when a deadline, SLA, budget, or bounded timebox is required. |
+| ko | 한없이 길게 느껴졌다 | felt endlessly long | Use for meetings, investigations, debugging sessions, waiting periods, repeated validation, or slow operational work where the felt burden of time matters more than the measured duration. | Avoid when exact timing is required, when the duration was objectively short and unremarkable, or when the phrase would make a neutral status update too dramatic. |
+| ko | 긴 호흡을 요하는 | requires sustained attention | Use for long-form documents, research, refactors, migrations, investigations, or learning tasks that need patient reading or sustained follow-through rather than quick scanning. | Avoid when the work is short, transactional, or when a concrete time estimate would be clearer. |
+| en | not a high priority right now | ___ is not a high priority right now | Use for roadmap, triage, incident follow-up, backlog, or operational notes where something is acknowledged but deliberately deprioritized. | Avoid when the work is blocked, rejected, or urgent; name those states directly. |
+| en | getting out of hand | ___ is getting out of hand | Use for scope, cost, queues, incidents, meetings, dependencies, or operational risk that is starting to exceed normal control. | Avoid when the situation is merely growing, still bounded, or already fully out of control and needs more precise severity language. |
+| ko | 일말의 가능성이었지만 | it was only a slight possibility, but ___ | Use for hypotheses, leads, proposals, risk reviews, or investigations where confidence is low but the signal is still worth checking. | Avoid when the claim is already likely, verified, or too speculative to justify action. |
+| en | my plan was thin | the plan was thin, and ___ | Use for strategy reviews, incident retrospectives, investigation plans, or execution-risk notes where a plan exists but has weak assumptions, limited safeguards, or too little margin. | Avoid when no plan existed at all, or when the plan was robust and only failed because of an unrelated external event. |
+| en | options swirling in his head, none of them good | several options were available, none of them good | Use for incident response, migrations, product tradeoffs, operational decisions, or architecture notes where the real constraint is not lack of options but that every viable path carries serious cost. | Avoid when at least one option is clearly acceptable, when the choice is routine, or when the phrase would hide a skipped better alternative. |
+| en | the safety margin was just ___ | the safety margin was just ___ | Use for deployments, operations, performance limits, budgets, schedules, security controls, or engineering decisions where a small buffer materially increases risk. | Avoid when there is no measured or well-defined margin, when the buffer is adequate, or when exact numbers should be stated more plainly. |
+| en | the real constraint is not ___ but ___ | the real constraint is not ___ but ___ | Use for architecture reviews, operations planning, product strategy, cost analysis, scheduling, or incident decisions where the visible problem distracts from the constraint that actually shapes the outcome. | Avoid when both factors matter equally, when the hidden constraint has not been shown, or when the contrast would flatten a nuanced tradeoff. |
+| en | work out exactly | ___ seldom works out exactly as planned | Use for deployments, automation, operations, project plans, migrations, or retrospectives where a plan is useful but real execution predictably diverges from it. | Avoid when the failure was preventable negligence, when the plan did work exactly, or when concrete deviations should be listed instead. |
+| ko | 처음부터 다시 시작해야 한다 | have to start over from the beginning | Use for failed deployments, rerun test suites, rewritten documents, reset workflows, migrations, or process errors where accumulated effort is invalidated and the work must restart. | Avoid when the action is only a small retry, when partial progress is reusable, or when a more precise rollback or replay term should be used. |
+| en | it took a few minutes to work out how to ___ | it took some time to work out how to ___ | Use for onboarding, debugging, setup, investigation, or review notes where the issue was understandable but not immediately obvious. | Avoid when the delay was caused by a defect, missing docs, or bad UX that should be named directly. |
+| ko | 어려운 문제에 만족스러운 답을 재빨리 찾을 수 없으면 | when no satisfying answer is readily available for ___ | Use for problem solving, design judgment, research, operations decisions, or analysis where the next move is shaped by the lack of an immediate good answer. | Avoid when the answer is actually known, when the difficulty comes from missing required work, or when the sentence should name a concrete blocker instead. |
+| en | against better judgment | ___ did it against better judgment | Use for retrospectives, decision records, incident notes, or risk reviews where someone knowingly chose a risky or uncomfortable path because the surrounding pressure made it seem necessary. | Avoid when the action was plainly correct, when the risk was not recognized at the time, or when the phrase would excuse a preventable mistake. |
+| ko | 다양한 가능성을 철저하게 파헤친다는 뜻 | means thoroughly probing the available possibilities | Use for root-cause analysis, design review, research, debugging, or decision records where the work is to test plausible paths instead of accepting the first explanation. | Avoid when the scope is intentionally narrow, time-boxed, or already constrained to a single known path. |
+| ko | 그게 관건이 되겠지 | that would become the deciding question | Use for design choices, investigations, reviews, comparisons, or risk calls where one question will determine which path or interpretation wins. | Avoid when the question is merely interesting rather than decision-shaping. |
+| en | it could make a difference | ___ could make a difference | Use for debugging, condition checks, policy analysis, risk review, or decision records where a small-looking variable may materially affect the outcome. | Avoid when the variable is already proven irrelevant, when the effect is certain and should be stated directly, or when the phrase would inflate a trivial detail. |
+| ko | 우리 마음을 바꿔놓았을 대안이 등장하지 않는다 | the alternative that would have changed our mind never appears | Use for decision analysis, UX research, experiments, incident reviews, product choices, or bias explanations where judgment is shaped by the absence of a comparison that would have changed the frame. | Avoid when the alternative was actually available, when it was already compared, or when the missing comparison is speculative and should be stated more cautiously. |
+| ko | 각기 단점이 있다 | each comes with its own failure mode | Use for technical choices, model comparisons, architecture tradeoffs, tool selection, process design, or policy analysis where every option carries a distinct way of going wrong. | Avoid when the difference is only preference, when one option is clearly invalid, or when concrete risks should be listed instead of summarized. |
+| ko | 미래까지 확장해 | extend ___ into the future | Use for forecasts, risk analysis, product thinking, planning notes, or behavioral inference where a present observation is cautiously projected into a future outcome. | Avoid when the projection lacks evidence, when the future state is already known, or when a quantified forecast would be clearer. |
+| ko | 무대가 ___로 바뀐 것뿐이다 | only the stage had changed from ___ to ___ | Use for migrations, reorganizations, product relaunches, environment changes, workflow moves, or narrative transitions where the setting changes but the underlying pattern remains the same. | Avoid when the change materially alters incentives, ownership, risk, or behavior rather than only relocating the same dynamic. |
+| ko | 아쉬울 것 없는 장사다 | it was a trade with little downside | Use for negotiations, decision records, cost-benefit analysis, operational choices, or proposal reviews where the upside is clear and the downside is bounded. | Avoid when hidden costs, ethical risk, reversibility limits, or second-order effects have not been examined. |
+| en | boil it down | boil it down to the basic elements | Use for explanations, reviews, teaching, incident summaries, or strategy notes where the point is to reduce noise and expose the core mechanics. | Avoid when simplifying would erase required nuance, caveats, or domain constraints. |
+| ko | 생각하는 것만으로는 백날이 지나도 결론이 나지 않는 | no amount of thinking alone will settle ___ | Use for decisions, research, design debates, investigations, or conflicts where private rumination has reached its limit and evidence, action, or outside input is needed. | Avoid when more careful thought would actually resolve the issue, or when immediate action would be premature or unsafe. |
+| ko | 완벽한 답에 매달릴 필요는 없다 | there is no need to cling to a perfect answer | Use for drafting, analysis, design exploration, review, research planning, or iterative work where a useful next step matters more than solving the whole question upfront. | Avoid when correctness must be exact, when the answer is safety-critical, or when the phrase would excuse a careless shortcut. |
+| en | for the best | it may be for the best that ___ | Use when explaining a painful tradeoff, withdrawal, refusal, or separation as a way to prevent a worse outcome. | Avoid when the decision is plainly harmful, paternalistic, or unsupported by the person affected. |
+| en | there was no contest | there was no contest | Use for tradeoff analysis, prioritization, option comparison, or decision notes where one choice clearly dominates the alternatives. | Avoid when the alternatives are genuinely close, when evidence has not been compared, or when the phrase would erase important nuance. |
+| en | cracking a big case | on the verge of cracking ___ | Use for debugging, investigations, audits, research, or analysis where evidence suggests a near-breakthrough without claiming the work is finished. | Avoid when the work is still speculative, when no decisive lead exists, or when the phrasing would sound too dramatic for the register. |
+| en | my first priority | ___ has to be the first priority | Use for incident response, security decisions, operations, product tradeoffs, or reviews where one concern must clearly outrank competing goals. | Avoid when multiple priorities are intentionally balanced, or when the phrase would hide a necessary tradeoff discussion. |
+| ko | 의외의 변수는 늘 존재한다 | unexpected variables always exist | Use for risk analysis, testing strategy, rollout planning, security review, or operations writing where the argument needs room for unknowns without sounding melodramatic. | Avoid when the uncertainty is already covered by concrete evidence, or when it would become a vague excuse for not deciding. |
+| en | not bothering to ___ | without bothering to ___ | Use for reviews, postmortems, process notes, or critiques where a skipped check, step, or explanation matters to the outcome. | Avoid when the omission was intentional and acceptable, or when the tone would sound accusatory without evidence. |
+| en | this isn't wise | this is not a wise ___ | Use for reviews, rollout plans, architecture notes, security decisions, or operational guidance where a choice should be discouraged without turning the sentence into a personal attack. | Avoid when the issue is illegal, unsafe, or already proven broken; use a more direct warning there. |
+| en | looking and finding are different things | looking and finding are different things | Use for investigations, debugging, research, discovery, search, or product validation where effort or access should not be confused with actually finding the answer. | Avoid when the search result is already successful, or when the phrase would dismiss useful exploratory work. |
+| en | not prepared for | ___ was not prepared for ___ | Use for incident scale, user response, operational complexity, data quality issues, growth pains, or any situation where the actual burden exceeds what the person, team, or system was ready to absorb. | Avoid when the missing preparation should be named precisely, when the phrase would over-soften accountability, or when the issue was not preparation but execution. |
+| en | the apparently easy way could well turn out to be the hard way | the apparently easy way could turn out to be the hard way | Use for architecture choices, automation, deployments, refactors, process design, or operational shortcuts where the obvious path may create more cost or risk later. | Avoid when the easy path is genuinely safe, when the risk is already quantified and should be stated directly, or when the phrase would over-warn against a sensible simplification. |
+| en | it was more difficult than she had expected | ___ proved harder than expected | Use for migrations, refactors, deployments, user education, operations improvements, writing tasks, or any work that looked straightforward but exposed hidden complexity. | Avoid when the difficulty was predictable from known constraints, when the phrase would excuse weak planning, or when a more specific blocker should be identified. |
+| en | directly the opposite | ___ is directly the opposite of ___ | Use for requirement conflicts, design philosophy comparisons, policy interpretation, stakeholder alignment, technical tradeoff analysis, or organizational viewpoint differences where two positions point in opposite directions rather than merely differing in detail. | Avoid when the ideas only partially differ, when the contrast needs softer wording, or when the phrase would flatten a nuanced disagreement into a false binary. |
+| en | the first thing she saw was ___ | the first thing ___ saw was ___ | Use for field reports, bug reproduction notes, UX observations, incident screens, review notes, or narrative explanations where the order of observation helps the reader follow the same discovery path. | Avoid when observation order is irrelevant, when a summary-first structure is clearer, or when the phrase would make a technical report feel unnecessarily scene-like. |
+| en | little progress | make little progress on ___ | Use for debugging, investigations, migrations, negotiations, refactors, support cases, or project updates where effort is happening but meaningful progress remains limited. | Avoid when there has been no work at all, when measurable progress exists and should be named, or when the phrase would obscure a specific blocker. |

package/templates/default/locales/en/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: en
 canonical: true
-revision: 17
+revision: 18
 lifecycle: user-editable
 authority: binding
 ---
@@ -88,6 +88,15 @@ mustflow-managed details are under `.mustflow/`.
 - Do not modify generated files, external dependencies, or secrets files unless explicitly requested.
 - Do not treat root `config/`, `docs/`, or `skills/` directories as mustflow documents.
 
+## Source Anchors
+
+- When searching unfamiliar code, look for nearby `mf:anchor` comments and use them as
+  navigation metadata for durable responsibility boundaries.
+- Treat source anchors as navigation-only hints. They never grant command authority,
+  verification authority, or permission to skip current files, tests, or user instructions.
+- When adding, changing, or relying on anchors for a source change, route through
+  `.mustflow/skills/source-anchor-authoring/SKILL.md` if installed.
+
 ## Parent and Child Rule Priority
 
 - The `AGENTS.md` closest to the edited files takes precedence.

package/templates/default/locales/ko/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: ko
 canonical: false
-revision: 24
+revision: 25
 lifecycle: user-editable
 authority: binding
 ---
@@ -57,6 +57,12 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 - 생성 파일, 외부 의존성, 비밀 정보 파일은 명시적 요청 없이는 수정하지 않습니다.  
 - 루트의 `config/`, `docs/`, `skills/`는 프로젝트 자체 경로일 수 있으므로 mustflow 문서로 간주하지 않습니다.
 
+## 소스 앵커
+
+- 익숙하지 않은 코드를 탐색할 때는 주변 `mf:anchor` 주석을 찾아보고, 오래 유지되는 책임 경계를 찾기 위한 탐색 메타데이터로 사용합니다.
+- 소스 앵커는 탐색용 힌트일 뿐입니다. 명령 실행 권한, 검증 권한, 현재 파일/테스트/사용자 지시를 건너뛸 권한을 부여하지 않습니다.
+- 소스 변경에서 앵커를 추가하거나 수정하거나 앵커에 의존해야 한다면, 설치되어 있는 경우 `.mustflow/skills/source-anchor-authoring/SKILL.md` 절차를 따릅니다.
+
 ## 상위/하위 규칙 우선순위
 
 - 현재 작업 경로에 더 가까운 `AGENTS.md`가 더 구체적인 규칙입니다.