Pith. sign in

REVIEW 3 major objections 5 minor 25 references

Architectural Degradation: Definition, Motivations, Measurement and Remediation Approaches

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read This multivocal review of 108 studies claims architectural degradation is both technical and organizational, and that while detection is well-studied, continuous remediation is missing.

desk verdict Largely useful multivocal synthesis with a credible detection-vs-remediation gap; the 50% knowledge-debt claim contradicts the paper's own Table 13 and must be fixed before the taxonomy is used as a baseline. read the letter →

arxiv 2507.14547 v1 pith:WVOXP2G4 submitted 2025-07-19 cs.SE

classification cs.SE
keywords softwarearchitecturearchitecturaldegradationerosiondecaytechnicaldebtmultivocalliteraturereviewmetricsremediationapproaches
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a systematic, multivocal review of 108 studies (1992–2024) aiming to unify how software architectural degradation—erosion, decay, or aging—is defined, measured, and remediated. It claims that degradation is not only a code-level or design-level problem but a socio-technical one: poor documentation, hasty fixes, time pressure, and knowledge loss all drive the same underlying drift between intended and actual architecture. The review finds that researchers and practitioners have produced 54 metrics and 31 measurement techniques, mostly for smells, coupling and cohesion, and evolution, but that these are rarely connected to tools that repair or prevent degradation. The central conclusion is that detection is well-studied while continuous, preventive remediation is missing, and future effort should build integrated pathways from metrics to tools to repair logic.

What carries the argument

The central machinery is the debt-layer taxonomy (architectural, code, and process debt) derived from axial coding of the primary studies, used to classify definitions, motivations, metrics, measurement approaches, tools, and remediation strategies. The other load-bearing instrument is the Sankey-style flow diagram that traces studies from measurement approaches through metrics to tools and remediation, making visible the “No Metrics”, “No Tool”, and “No Remediation” bottlenecks. These two devices together carry the argument that degradation is socio-technical and that remediation is disconnected from detection.

What would settle it

Run an independent replication of the coding: have a fresh team classify the same 108 primary studies' motivations using the paper's debt categories, then compare the resulting percentages (for example, knowledge debt as 50% of process debt); if the shares move substantially or inter-rater agreement is poor, the taxonomy's numerical claims are unstable.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes a taxonomy of degradation causes split into architectural debt, code debt, combined debt, and process debt, and proposes a unified definition: architectural degradation is the progressive divergence between implemented and intended architecture, caused by repeated violations of rules and design principles and by cumulative code-level changes, leading to loss of key properties and rising complexity. The discovery is the gap structure: the field is mature at recognizing degradation but weak at acting on it. A flow analysis that traces studies from measurement approaches through metrics to tools and remediation shows that most approaches either stop before defining concrete metrics or lead to “No Tool” and “No Remediation” dead ends. The paper interprets this as evidence that metrics, tools, and repair logic are not integrated, and that degradation is both technical and organizational.

Load-bearing premise

The paper's quantitative claims depend on the three senior authors' coding of primary studies into architectural, code, and process debt, so a different coding team could shift the percentages that drive the gap analysis.

Editorial extensions

If this is right

  • If degradation is socio-technical, then process debt—especially knowledge loss, turnover, and time pressure—must be measured and managed alongside structural metrics.
  • The 54 metrics and 31 measurement techniques catalogued here give researchers and practitioners a baseline for choosing indicators rather than inventing new ones.
  • Because most tools detect smells or violations but do not connect to repair, CI/CD pipelines will need tools that trigger remediation recommendations from metric thresholds.
  • A unified definition of architectural degradation could let empirical studies compare results across terminologies like erosion, decay, and aging.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the knowledge-debt finding suggests a testable hypothesis that repositories with higher developer turnover should show faster architectural decay even when code quality metrics are controlled.
  • Beyond the paper: the taxonomy provides categories for building a degradation risk score that combines process indicators (time pressure, turnover, documentation freshness) with structural metrics (coupling, smells), though the paper itself does not propose such a formula.
  • Beyond the paper: because the paper finds no tools that measure knowledge loss, a natural next step is to mine developer communication and onboarding documents for process-debt signals.
  • Beyond the paper: if the “No Metrics” bottleneck is real, reflection-model and smell-detection studies could be re-analyzed to attach existing metrics to their qualitative findings, turning descriptive studies into quantitative baselines.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. This paper presents a multivocal literature review (MLR) of 108 primary studies (1992–2024) on architectural degradation, defined broadly to include erosion, decay, and aging. The authors extract definitions, motivations (categorized as architectural, code, combined, and process debt), metrics, measurement approaches, tools, and remediation strategies. The main claims are that the concept has shifted from a purely technical to a socio-technical phenomenon, that process-related causes (especially knowledge loss) are underappreciated, that existing metrics and tools are mostly structural and disconnected from remediation, and that continuous, preventive remediation is lacking. The paper proposes a unified definition and a research agenda. A replication package is provided at a Zenodo DOI.

Significance. If the quantitative inconsistencies are corrected, this would be a valuable synthesis for the software architecture community. The multivocal scope (white and gray literature), the explicit taxonomy of debt types, and the spotlight on the disconnect between detection and remediation are useful contributions. The paper also ships a replication package, which is a strength. The qualitative narrative—that degradation is socio-technical and that remediation is underdeveloped—is plausible and consistent with the broader literature. However, the quantitative support for some central claims is currently unreliable, and the significance of the contribution depends on fixing these issues.

major comments (3)
  1. [§4.2, §5, Table 13, Figure 7, Abstract] The claim that knowledge debt accounts for 50% of Process Debt is not supported by the paper's own data. Table 13 reports Process Debt as 22 primary studies (20.4%) and the Knowledge sub-category as 7 primary studies (6.5%), i.e., 7/22 ≈ 31.8%. Figure 7 lists Knowledge as (10, 9.3%), which would give at most 8/22 ≈ 36.4% if the organizational-best-practices-unfollowed row is included. The text in the Abstract, Section 4.2 (key insight #3), and Section 5 (first discussion bullet) repeats the 50% figure, and the text's other process-debt percentages (Development Practices 20.8%, Governance 29.2%, Knowledge 50%) sum to 100% but do not match the counts in Table 13 (5, 3/10, and 7 respectively). Because the predominance of knowledge debt is a load-bearing quantitative justification for the socio-technical reframing, this internal inconsistency must be resolved: either the tables are corrected to match the text, or the text must be revised to state the percentages actually derivable from the data.
  2. [§4.3, Table 14, Figure 8] The metric counts in RQ3 are internally inconsistent. The text states that 54 metrics were identified, and Table 14 lists 24 architectural-debt metrics and 30 code-debt metrics, which sum to 54. However, the table's own header columns report 'Architectural debt (13, 12%)' and 'Code debt (15, 13.9%)', which sum to only 28 metrics and 25.9%. Figure 8 repeats these conflicting labels (e.g., Architectural Debt shown as 13, 12% with a separate '24 Metrics' tag). A reader cannot determine the actual distribution of metrics across the two categories from the paper as written. Since the abstract and conclusions explicitly cite '54 metrics', the authors should correct the table and figure headers so that the category totals match the listed items.
  3. [§4.2, Figures 5–7, Tables 10–13] Several percentage labels in the motivation figures and tables do not match each other or the text. Specific examples: Figure 6 shows Code Debt as (48, 44.4%) while its child 'Implementation & Code Quality' is (52, 48.1%), so the child count exceeds its parent; Table 11 reports this child as (50, 46.3%), a third value. Figure 7 reports Knowledge as (10, 9.3%) while Table 13 reports Knowledge as (7, 6.5%). The text in §4.2 says the Technological Evolution category is 1.9% for both Architectural Debt and Code Debt, but Table 10 and Table 11 each report it as (1, 0.9%). These discrepancies make the quantitative synthesis of motivations unreliable as presented. The authors should audit all percentages in the results sections against the appendix tables and ensure that each percentage is computed on a stated, consistent denominator.
minor comments (5)
  1. [§3.2.1, §6] The search string restricts to 'software architec*' in title/abstract together with degradation/aging/erosion/decay terms. Although snowballing is used, relevant studies using other terminology (e.g., 'design erosion' without 'software architecture') may be missed. Please make this limitation explicit in the threats-to-validity section, beyond the general conclusion-validity sentence.
  2. [§3.4] The axial coding of motivations was performed by the three most senior authors, and the inter-rater agreement for this step is not reported (the paper reports agreement only for study selection). Please report a kappa statistic or equivalent for the classification step, or at least describe the reconciliation process in more detail.
  3. [§4 and figures] There are several typographical errors and inconsistent labels throughout: 'colored threes' should be 'colored trees' (§4 opening), 'hone hand' should be 'one hand' (§4.5), 'sepraterly' should be 'separately' (§4.2), 'gwoing' should be 'growing' (§5), 'Idnetifying' is misspelled in Figure 11, and 'Statistic analysis' in Figure 11 should be 'Static analysis'.
  4. [§4.4, Figure 9] The abstract and results mention '31 measurement techniques', but the total is not clearly derived from the categories in Figure 9 or Table 15. Please state explicitly how the count of 31 is obtained, and ensure that the counts in Figure 9 sum to that number.
  5. [§6] The conclusion-validity paragraph says the snowballing process 'resulted in one additional relevant paper', while Table 4 and the text in §3.2.4 report +19 papers from snowballing. This appears to be a typo and should be corrected to '19 additional papers' or rephrased if a different step is meant.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: this multivocal literature review synthesizes 108 external primary studies; its taxonomy is borrowed from external prior work, and its conclusions are not derived from the authors' own prior results or from fitted parameters.

full rationale

The paper is a synthesis of external primary studies. Its classification schema is explicitly grounded in the Technical Debt taxonomy of Li et al. (2015), an external source: 'we started to conceptualize the classification schema according to the Technical Debt classification defined by (Li et al., 2015)'. The quantitative results, such as the motivations percentages and the 54 metrics, are extracted and coded from the 108 included studies rather than fitted to the paper's own conclusions. The self-citations (Lenarduzzi et al., 2021; Janes et al., 2023) are used only as contextual background or methodological precedent for gray literature searches, not as load-bearing evidence for the paper's central claims. The paper's unified definition of architectural degradation is a synthesis of the definitions found in the reviewed studies, and the claim that degradation is socio-technical is a summary of the categorized motivations rather than a prediction derived from an input by construction. The internal inconsistency noted by the skeptic, where the text states knowledge debt constitutes 50% of Process Debt while Table 13 implies roughly 32%, is a data consistency or correctness issue, not a circularity issue, because the knowledge-debt percentage is not used to define the Process Debt category or to force the conclusion. No step was found in which an input was defined in terms of the output, a fitted parameter was renamed as a prediction, or a uniqueness theorem from the authors' own prior work was imported to forbid alternatives. The review is therefore self-contained as a synthesis, and the appropriate circularity score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central claims rest on hand-chosen inclusion thresholds, a borrowed technical-debt taxonomy, and the assumption that the 108 primary studies are faithfully reported. No new entities or fitted constants are introduced; the numerical findings are counts and percentages derived from the authors' coding of the primary studies.

free parameters (2)
  • Peer-reviewed paper quality threshold = 2.0 on 0-4 Likert scale
    Papers scoring below 2 on the Dybå and Dingsøyr (2008) checklist were excluded; this hand-chosen cutoff removed 2 of 104 papers and shapes the final corpus (Section 3.2.4).
  • Gray literature quality threshold = 0.5 on 0-1 scale
    Gray literature sources scoring below 0.5 on the extended Garousi et al. (2019) criteria were rejected; a more stringent cutoff would change the 6 gray sources included (Section 3.2.5).
assumptions (4)
  • domain assumption Primary studies report their definitions, causes, metrics, and tools accurately enough for synthesis.
    The MLR extracts data 'exclusively based on what is reported in the papers, without any kind of personal interpretation' (Section 3.3). If a primary study misrepresents its tool or results, the synthesis inherits that error.
  • domain assumption The technical debt taxonomy of Li et al. (2015) is a valid basis for classifying degradation motivations.
    Section 3.4 says the classification schema starts from Li et al.'s technical debt classification; the three-layer structure (architectural, code, process) and all resulting percentages depend on this choice.
  • domain assumption The quality assessment instruments are valid filters for inclusion.
    Sections 3.2.4 and 3.2.5 apply the Dybå and Dingsøyr and Garousi et al. checklists; their validity and the 0.5 gray-literature cutoff are assumed rather than demonstrated.
  • domain assumption Multivocal literature review is an appropriate method to answer the six research questions.
    The study adopts Garousi et al. (2019) MLR guidelines; the conclusions about research gaps inherit the limitations of the method, including search coverage and coding subjectivity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Architectural Degradation: Definition, Motivations, Measurement and Remediation Approaches." pith.science (2026). https://pith.science/paper/WVOXP2G4

@misc{pith2026250714547,
  author       = {Pith},
  title        = {Pith review of: Architectural Degradation: Definition, Motivations, Measurement and Remediation Approaches},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WVOXP2G4}},
  note         = {Machine review of arXiv:2507.14547}
}
read the original abstract

Architectural degradation, also known as erosion, decay, or aging, impacts system quality, maintainability, and adaptability. Although widely acknowledged, current literature shows fragmented definitions, metrics, and remediation strategies. Our study aims to unify understanding of architectural degradation by identifying its definitions, causes, metrics, tools, and remediation approaches across academic and gray literature. We conducted a multivocal literature review of 108 studies extracting definitions, causes, metrics, measurement approaches, tools, and remediation strategies. We developed a taxonomy encompassing architectural, code, and process debt to explore definition evolution, methodological trends, and research gaps. Architectural degradation has shifted from a low-level issue to a socio-technical concern. Definitions now address code violations, design drift, and structural decay. Causes fall under architectural (e.g., poor documentation), code (e.g., hasty fixes), and process debt (e.g., knowledge loss). We identified 54 metrics and 31 measurement techniques, focused on smells, cohesion/coupling, and evolution. Yet, most tools detect issues but rarely support ongoing or preventive remediation. Degradation is both technical and organizational. While detection is well-studied, continuous remediation remains lacking. Our study reveals missed integration between metrics, tools, and repair logic, urging holistic, proactive strategies for sustainable architecture.

Figures

Figures reproduced from arXiv: 2507.14547 by the authors.

Figure 1
Figure 1. Search and Selection Process used an asterisk character (*) for the second term group, such as "software architecture*," to get all possible term variations, such as plurals and verb conjugations. To increase the likelihood of finding papers that addressed our goal, we applied the search string to the title and abstract. 3.2.2. Bibliographic Sources For retrieving the peer-reviewed paper, we selected the list of rel… view at source ↗
Figure 2
Figure 2. Debt Layers [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Selected Papers per Year identify this decline as erosion, while [SP19], [SP66], and [SP100] refer to it as degradation. Uniquely, [SP53] intro￾duces the concept of architecture aging, directly addressing the aspect of long-term deterioration over time. Similarly, [SP57] characterizes architectural decay as an ongoing de￾cline in overall architectural quality. ¤ 1. What is Architectural Degradation Architectural deg… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Architectural degradation definition and its evolution (RQ1 ) The first sub-category, Development Practices, accounts for approximately 20.8% of the identified Process Debt mo￾tivations. Within this category, issues predominantly arise from sub-optimal development proc…
Figure 5
Figure 5. Figure 5: Architectural degradation motivations - Architectural debt main category (RQ1 ) - (#, %: number and percentage of unique SPs) Ahmad et al.: Preprint submitted to Elsevier Page 12 of 28 [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6: Architectural degradation motivations - Code debt main category (RQ1 ) - (#, %: number and percentage of unique SPs) geographically or organizationally, maintaining a consis￾tent and coherent architecture becomes challenging. Addi￾tionally, the inadequate implementatio…
Figure 7
Figure 7. Figure 7: Architectural degradation motivations - Process debt main category (RQ1 ) (#, %: number and percentage of unique SPs) analysis (6% [SP8], [SP14], [SP29], [SP70]), integrating both proactive and reactive measures to maintain architec￾tural alignment, and coupling and co…
Figure 8
Figure 8. Figure 8: Architectural degradation metrics (RQ2 ) - (#, %: number and percentage of unique SPs) ¤ 5. Measurement Approaches Architectural Debt. Predominantly evaluated through Architectural Design (73.1%), with key methods including architectural quality analyses like reflectio…
Figure 9
Figure 9. Figure 9: Measuring approaches (RQ3 ) - (#, %: number and percentage of unique SPs) Ahmad et al.: Preprint submitted to Elsevier Page 17 of 28 [PITH_FULL_IMAGE:figures/full_fig_p017_9.png]
Figure 10
Figure 10. Figure 10: Measuring tools (RQ4 ) - (#, %: number and percentage of unique SPs) Ahmad et al.: Preprint submitted to Elsevier Page 19 of 28 [PITH_FULL_IMAGE:figures/full_fig_p019_10.png]
Figure 11
Figure 11. Figure 11: Connections from Measurement Approaches to Remediation Approaches stop short of proposing actionable remediation strategies or long-term interventions. Tools are often used diagnostically rather than proactively, and process-level challenges are rarely addressed with …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 18 canonical work pages

  1. [1]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in ":" * " " * FUNCTION f...

  2. [2]

    , author Esposito, M

    author Akbar, M.A. , author Esposito, M. , author Hyrynsalmi, S. , author Kumar, K.D. , author Lcnarduzzi, V. , author Li, X. , author Mehraj, A. , author Mikkonen, T. , author Moreschini, S. , author Makitalo, N. , author Oivo, M. , author Paavonen, A.S. , author Parveen, R. , author Smolander, K. , author Su, R. , author Systa, K. , author Taibi, D. , a...

  3. [3]

    , author Zulzalil, H.B

    author Baabad, A. , author Zulzalil, H.B. , author Hassan, S. , author Baharom, S.B. , year 2020 . title Software architecture degradation in open source software: A systematic literature review . journal IEEE Access volume 8 , pages 173681--173709 . :10.1109/ACCESS.2020.3024671

  4. [4]

    , author Zulzalil, H.B

    author Baabad, A. , author Zulzalil, H.B. , author Hassan, S. , author Baharom, S.B. , year 2022 . title Characterizing the architectural erosion metrics: A systematic mapping study . journal IEEE Access volume 10 , pages 22915 – 22940 . :10.1109/ACCESS.2022.3150847. note cited by: 3; All Open Access, Gold Open Access

  5. [5]

    , year 1995

    author Campbell-Kelly, M. , year 1995 . title Development and structure of the international software industry, 1950-1990 . journal Business and economic history , pages 73--110

  6. [6]

    , author Strauss, A

    author Corbin, J. , author Strauss, A. , year 2014 . title Basics of qualitative research: Techniques and procedures for developing grounded theory . publisher Sage publications

  7. [7]

    , author Balasubramaniam, D

    author de Silva , L. , author Balasubramaniam, D. , year 2012 . title Controlling software architecture erosion: A survey . journal Journal of Systems and Software volume 85 , pages 132--151

  8. [8]

    , year 1982

    author DeMarco, T. , year 1982 . title Controlling Software Projects: Management, Measurement, and Estimation . publisher Prentice-Hall , address Englewood Cliffs, NJ

Show all 25 references
  1. [9]

    , year 1954

    author Drucker, P.F. , year 1954 . title The Practice of Management . publisher Harper & Row , address New York

  2. [10]

    , author Dings yr, T

    author Dyb , T. , author Dings yr, T. , year 2008 . title Empirical studies of agile software development: A systematic review . journal Inf. Softw. Technol. volume 50 , pages 833--859

  3. [11]

    , author Felderer, M

    author Garousi, V. , author Felderer, M. , author Mäntylä, M.V. , year 2019 . title Guidelines for including grey literature and conducting multivocal literature reviews in software engineering . journal Information and Software Technology volume 106 , pages 101--121

  4. [12]

    , author Rao, G.S

    author Gibson, D.H. , author Rao, G.S. , year 1992 . title Design of the ibm system/390 computer family for numerically intensive applications: An overview for engineers and scientists . journal IBM journal of research and development volume 36 , pages 695--711

  5. [13]

    , author Blom, M

    author Herold, S. , author Blom, M. , author Buckley, J. , year 2016 . title Evidence in architecture degradation and consistency checking research: preliminary results from a literature review , publisher Association for Computing Machinery , address New York, NY, USA . :10.1...

  6. [14]

    , author Li, X

    author Janes, A. , author Li, X. , author Lenarduzzi, V. , year 2023 . title Open tracing tools: Overview and critical comparison . journal Journal of Systems and Software , pages 111793

  7. [15]

    , author Brereton, P

    author Kitchenham, B. , author Brereton, P. , year 2013 . title A systematic review of systematic review process research in software engineering . journal Information & Software Technology volume 55 , pages 2049--2075

  8. [16]

    , author Charters, S

    author Kitchenham, B. , author Charters, S. , year 2007 . title Guidelines for performing systematic literature reviews in software engineering

  9. [17]

    , author Besker, T

    author Lenarduzzi, V. , author Besker, T. , author Taibi, D. , author Martini, A. , author Fontana, F.A. , year 2021 . title A systematic literature review on technical debt prioritization: Strategies, processes, factors, and tools . journal Journal of Systems and Software vol...

  10. [18]

    , author Liang, P

    author Li, R. , author Liang, P. , author Soliman, M. , author Avgeriou, P. , year 2021 . title Understanding architecture erosion: The practitioners’ perceptive , in: booktitle 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC) , pp. pages 311--322 . ...

  11. [19]

    , author Avgeriou, P

    author Li, Z. , author Avgeriou, P. , author Liang, P. , year 2015 . title A systematic mapping study on technical debt and its management . journal Journal of Systems and Software volume 101 , pages 193--220 . :10.1016/j.jss.2014.12.027

  12. [20]

    , author Wright, C.C

    author Sim, J. , author Wright, C.C. , year 2005 . title The kappa statistic in reliability studies: Use, interpretation, and sample size requirements . journal Physical Therapy volume 85 , pages 257--268 . :10.1093/ptj/85.3.257

  13. [21]

    , author Blom, M

    author Sinkala, Z.T. , author Blom, M. , author Herold, S. , year 2018 . title A mapping study of software architecture recovery for software product lines , in: booktitle Proceedings of the 12th European Conference on Software Architecture: Companion Proceedings , publisher A...

  14. [22]

    , year 1883

    author Thomson, W.L.K. , year 1883 . title Popular Lectures and Addresses, Vol. 1: Electrical Units of Measurement . publisher Macmillan and Co. , address London

  15. [23]

    , year 2014

    author Wohlin, C. , year 2014 . title Guidelines for snowballing in systematic literature studies and a replication in software engineering , in: booktitle EASE 2014

  16. [24]

    , author Mehmmod, Z

    author Zahid, M. , author Mehmmod, Z. , author Inayat, I. , year 2017 . title Evolution in software architecture recovery techniques — a survey , in: booktitle 2017 13th International Conference on Emerging Technologies (ICET) , pp. pages 1--6 . :10.1109/ICET.2017.8281704

  17. [25]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.