Merge remote-tracking branch 'origin/main'

.obsidian/core-plugins.json

@@ -21,7 +21,7 @@
   "random-note": false,
   "outline": true,
   "word-count": true,
-  "slides": false,
+  "slides": true,
   "audio-recorder": false,
   "workspaces": false,
   "file-recovery": true,

.obsidian/plugins/obsidian-git/data.json

@@ -16,8 +16,8 @@
   "listChangedFilesInMessageBody": false,
   "showStatusBar": true,
   "updateSubmodules": false,
-  "syncMethod": "merge",
+  "syncMethod": "rebase",
-  "mergeStrategy": "none",
+  "mergeStrategy": "ours",
   "customMessageOnAutoBackup": false,
   "autoBackupAfterFileChange": false,
   "treeStructure": false,

timestamped/2026-01-20_10-10-00.md

@@ -12,5 +12,5 @@ I added a [[small-tasks|task]] for it.
 [html-calculators](https://github.com/ZaneMeyers/html-calculators)
 
 I'm now certain that common estimating calculators
-(e.g. voltage drop)
+(e.g. [[voltage-drop]])
 could be easily replaced with documents like this one.

timestamped/2026-03-05_10-26-48.md

@@ -10,7 +10,7 @@ daily: "[[2026-03-05]]"
 
 ## Python SQLite Voltage Drop Calculator
 
-Python script to account for voltage drop
+Python script to account for [[voltage-drop]]
 based on various factors given in various forms
 
 Python to handle calculation, defaults.

timestamped/2026-05-21_08-12-01.md

@@ -15,9 +15,10 @@ requiring that we change several designations.
 He asked if this was a common occurrence,
 I replied that he should expect it to happen
 a couple dozen times per project.
+
 I've said often that I'm obsessive in my takeoff
-with the expectation that I will need to change most takeoffs,
+with the expectation that I will need to change most of them,
 but I only realized then
 that I am not expecting a revision to the RFP documents,
 but that my understanding of the requirements will change
-as I make new discoveries in takeoff.
+as I make new discoveries during the takeoff process.

timestamped/2026-05-22_11-57-18.md

@@ -31,7 +31,8 @@ See [[pdi-labor-plan]].
 > A less cautious man than I might wonder
 > if the negative bias apparent in Bid and ConEst
 > is indicative of systematic [[incentives|incentive]] gaming,
-> since if it we could change nothing of our process
+> since if it were undesirable
+> we could change nothing of our process
 > and simply add contingency to address it.
 
 ***

timestamped/2026-05-27_21-32-16.md

@@ -0,0 +1,37 @@
+---
+id: 2026-05-27T21:32:16-0400
+title: 2026-05-27 21:32:16
+tags: []
+daily: "[[2026-05-27]]"
+---
+# 2026-05-27 21:32:16
+
+While working on [[telecom-takeoff]] for [[303-mariposa-residence]]
+[[jared-defanti]] used (2) Cat5e + (1) RG6 assemblies for most outlets.
+We determined that (3) Cat5e assemblies would likely be required instead.
+Because the required assemblies do not exist,
+and the takeoff would have to be deleted
+and replaced with [[heating-designations]],
+I suggested leaving the existing work alone,
+citing that the limited information
+makes likely our superiors will have a different interpretation than us.
+**If we changed the takeoff then**
+**we would have to change it again.**
+
+> Ultimately we did change the takeoff
+> because there were less than a dozen outlets in the project.
+
+***
+
+This is a good example of a scope question
+which I believe should be saved for review,
+not raised with the senior.
+
+1. The maximum project cost impact of the decision is low,
+    being only the difference between RG6 and Cat5e.
+
+2. The result of the decision will not affect our future takeoff.
+
+3. We would waste more of the senior's time
+    in the overhead of explaining the project and the issue early,
+    than if it has to be fixed during the allotted time they prepared for.