Révisions pour Gemma4 HabitLang DSL

Télécharger en ZIP

ZZ a révisé ce gist 1781243652. Aller à la révision

Aucun changement

Z a révisé ce gist 1781220043. Aller à la révision

Aucun changement

Z a révisé ce gist 1779068861. Aller à la révision

Aucun changement

Z a révisé ce gist 1778404650. Aller à la révision

Aucun changement

Z a révisé ce gist 1777848178. Aller à la révision

Aucun changement

Z a révisé ce gist 1777848032. Aller à la révision

1 file changed, 123 insertions

HabitLang-DSL.md(fichier créé)

		@@ -0,0 +1,123 @@
1	+	To turn these prose-based habits into a Domain Specific Language (DSL), we need to shift from "advice" to "constraints and declarations."
2	+
3	+	I will call this language `HabitLang`. It is a declarative language used to define a team's "Development Philosophy" or "Quality Manifesto." Instead of writing a README, a team writes a `.habit` file that acts as a living specification for their workflow.
4	+
5	+	Below is the specification and the implementation of the rules in `HabitLang`.
6	+
7	+	---
8	+
9	+	### 1. The `HabitLang` Specification
10	+
11	+	Core Primitives:
12	+	* `policy`: A high-level directive that must be followed.
13	+	* `threshold`: A quantitative limit that triggers an action.
14	+	* `priority`: A ranking of importance (Immediate, Future, Ignorable).
15	+	* `constraint`: A hard rule that defines "Working" or "Done."
16	+	* `workflow`: A sequence of required steps.
17	+
18	+	---
19	+
20	+	### 2. The Rules translated into `HabitLang`
21	+
22	+	Here is how the 10 rules would be written in the DSL:
23	+
24	+	```python
25	+	// Rule 1: Commit Granularity
26	+	policy CommitSize {
27	+	limit: "compilable_unit",
28	+	goal: "effortless_revert",
29	+	warning: "if you feel you are taking this too far, you are doing it right"
30	+	}
31	+
32	+	// Rule 2: Refactoring Cadence
33	+	policy RefactorCycle {
34	+	commit_ratio: 0.5, // 50% of commits should be refactors
35	+	max_duration: 10m, // Continuous refactoring units
36	+	strategy: "make_easy_then_do_easy",
37	+	avoid: "big_refactor"
38	+	}
39	+
40	+	// Rule 3: Deployment & Value
41	+	policy Deployment {
42	+	liability: "undeployed_code",
43	+	measure_of_progress: "working_software",
44	+	definition_of_working: "deployed_and_contributing",
45	+	cost_tolerance: "high", // Hosting costs < knowledge of progression
46	+	}
47	+
48	+	// Rule 4: Testing Scope
49	+	policy TestScope {
50	+	trust: "framework_internals",
51	+	avoid: "testing_the_framework",
52	+	correlation: {
53	+	component_size: "small" -> test_burden: "low",
54	+	component_size: "large" -> test_burden: "high"
55	+	}
56	+	}
57	+
58	+	// Rule 5: Module Organization
59	+	policy ModulePlacement {
60	+	preference: "independent_construct",
61	+	forbidden: "jamming_into_existing_module",
62	+	lifecycle: "create_now -> home_later"
63	+	}
64	+
65	+	// Rule 6: API Design
66	+	workflow ApiDevelopment {
67	+	sequence: [TestFirst, Implement, Verify],
68	+	dogma_level: "low",
69	+	goal: "customer_perspective"
70	+	}
71	+
72	+	// Rule 7: Abstraction Trigger (The Rule of Three)
73	+	policy Abstraction {
74	+	copy_paste_limit: 2,
75	+	trigger: "third_occurrence",
76	+	action: "consolidate_abstraction",
77	+	preference: "wonky_parameterization" over "diverging_implementations"
78	+	}
79	+
80	+	// Rule 8: Design Evolution
81	+	policy DesignMindset {
82	+	state: "stale_by_default",
83	+	acceptance: "change_is_core",
84	+	metric_of_skill: "ease_of_changing_software"
85	+	}
86	+
87	+	// Rule 9: Technical Debt Classification
88	+	policy TechDebt {
89	+	categories: {
90	+	type_1: { label: "blocking_now", priority: "critical" },
91	+	type_2: { label: "blocking_later", priority: "high" },
92	+	type_3: { label: "might_block_later", priority: "ignore" }
93	+	},
94	+	focus: [type_1, type_2]
95	+	}
96	+
97	+	// Rule 10: Testability as a Signal
98	+	policy Testability {
99	+	signal: "difficult_to_test" -> "design_flaw",
100	+	remedy: ["extract_function", "create_test_utility"],
101	+	assertion: "tests_go_unwritten_due_to_friction_not_will"
102	+	}
103	+	```
104	+
105	+	---
106	+
107	+	### 3. How this DSL would be used (The "Runtime")
108	+
109	+	Since a DSL is useless without a way to apply it, here are three ways `HabitLang` could be "executed":
110	+
111	+	#### A. The Linter (Static Analysis)
112	+	A CLI tool scans your Git history and project structure:
113	+	* Check Rule 1 & 2: `habit-check` analyzes the last 100 commits. If `refactor_ratio` is < 0.5, it warns: "Your project is drifting away from Rule 2: Increase refactoring frequency."
114	+	* Check Rule 7: A static analyzer detects three nearly identical functions and flags: "Abstraction Trigger: Third occurrence detected. Consolidate now."
115	+
116	+	#### B. The PR Template (Human Process)
117	+	The DSL generates a dynamic Pull Request checklist based on the `.habit` file:
118	+	- [ ] Is this commit "small enough to be blissfully revertible"? (Rule 1)
119	+	- [ ] If this is a new API, were tests written first? (Rule 6)
120	+	- [ ] Does this add to "Type 1" or "Type 2" tech debt? (Rule 9)
121	+
122	+	#### C. The Onboarding Tool (Cultural Alignment)
123	+	When a new developer joins, they run `habit-init`, which transforms the `.habit` file into an interactive guide, explaining the "Why" behind these constraints, ensuring the team's "Good Habits" are codified and not just implied.

Plus récent Plus ancien