Input: Note on the Ferrand tender translation before I hand it back, and I am dictating it because my hands have had enough for one day and there is a lot to say. The file came in as a scan, which nobody told me, so the first two hours went on retyping rather than translating, and I have logged that separately because it is not translation time and should not be billed as translation time. On the substance, the source text is a French tender document written by somebody who is fond of very long sentences, and the house style for the client is short ones, so almost every paragraph needed splitting, and that is where the punctuation questions come from. The heading on the second section should read Clause four colon termination for convenience, because the source has a colon there and the client's own template uses colons in headings, so both reasons point the same way. In the schedule of charges the source runs three obligations into one sentence with commas, and commas will not hold that much weight in English, so the first obligation ends at delivery semicolon the second begins at inspection, and I have kept the same structure for the third rather than inventing a fourth sentence. There is one place I have flagged rather than decided. The source has an exclamation in the safety warning, which in French reads as emphasis and in English reads as shouting, and the client's guidance says never use one in a formal document, so in the margin note I have written Do not send exclamation mark and left the decision to whoever signs it off, because that is a tone judgement and not mine to make. A few smaller things. The colon in the citation on page eleven is wrong in the source and I have left it wrong with a note, because correcting somebody else's citation inside a tender is how you end up in an argument about what else you changed. The period the document keeps referring to is the guarantee period rather than a punctuation mark, which sounds obvious written down but caused me genuine trouble for about ten minutes because the sentence around it is about drafting. And the point the client made in the brief about matching the register of the original is the one thing I have consistently prioritised over literal accuracy, so if they read it back and it feels less formal than the French, that is deliberate and I can defend it line by line. Last thing, the glossary. I have added eleven terms and removed two that were wrong, and one of the two I removed had been wrong in every document we have sent that client for three years, which nobody had noticed, so somebody should decide whether we say anything about that or quietly stop using it. My view is we say something, but it is not my call and I would rather raise it here than in front of them.

Note on the Ferrand tender translation before I hand it back, and I am dictating it because my hands have had enough for one day and there is a lot to say. The file came in as a scan, which nobody told me, so the first two hours went on retyping rather than translating, and I have logged that separately because it is not translation time and should not be billed as translation time. On the substance, the source text is a French tender document written by somebody who is fond of very long sentences, and the house style for the client is short ones, so almost every paragraph needed splitting, and that is where the punctuation questions come from. The heading on the second section should read Clause four: termination for convenience, because the source has a colon there and the client's own template uses colons in headings, so both reasons point the same way. In the schedule of charges the source runs three obligations into one sentence with commas, and commas will not hold that much weight in English, so the first obligation ends at delivery; the second begins at inspection, and I have kept the same structure for the third rather than inventing a fourth sentence. There is one place I have flagged rather than decided. The source has an exclamation in the safety warning, which in French reads as emphasis and in English reads as shouting, and the client's guidance says never use one in a formal document, so in the margin note I have written Do not send! and left the decision to whoever signs it off, because that is a tone judgement and not mine to make. A few smaller things. The colon in the citation on page eleven is wrong in the source and I have left it wrong with a note, because correcting somebody else's citation inside a tender is how you end up in an argument about what else you changed. The period the document keeps referring to is the guarantee period rather than a punctuation mark, which sounds obvious written down but caused me genuine trouble for about ten minutes because the sentence around it is about drafting. And the point the client made in the brief about matching the register of the original is the one thing I have consistently prioritised over literal accuracy, so if they read it back and it feels less formal than the French, that is deliberate and I can defend it line by line. Last thing, the glossary. I have added eleven terms and removed two that were wrong, and one of the two I removed had been wrong in every document we have sent that client for three years, which nobody had noticed, so somebody should decide whether we say anything about that or quietly stop using it. My view is we say something, but it is not my call and I would rather raise it here than in front of them.


Input: The build fails on Windows only when the path has a


Input: The migration went fine and nobody noticed on the customer side, which was the whole point, but the backfill job ran slower than staging because


Input: The trustees discussed the building at length and the feeling in the room was that we should commission a second survey before we


Input: CVE-2026-4471 only matters if the attacker already has,


Input: I am going to be late because the bus


Input: The tracking number is nine four seven two,


Input: My name is spelled with two l s and the second one is,


Input: Speak oh flow needs the adapter, not a second model.

SpeakoFlow needs the adapter, not a second model.


Input: I asked cloud about the cold start and it suggested pinning llama dot see pee pee, but I think the real fix is loading pair a keet earlier.

I asked Claude about the cold start and it suggested pinning llama.cpp, but I think the real fix is loading Parakeet earlier.


Input: The write off will effect the quarterly numbers.

The write off will affect the quarterly numbers.


Input:
Test suite status, because I said I would write it down after the last time this came up in retro. The unit tests are 1,240 and they run in 40 seconds and they are fine and nobody complains about them. The integration tests are 180 and they take eleven minutes because each one spins a fresh Postgres container, and about six of them are flaky in a way that goes away on rerun, which means everybody reruns everything and nobody investigates.

I have looked at the six. Four of them share a fixture that seeds a user with a fixed email and they collide when the suite runs in parallel, and that is a real fix, one afternoon. The other two are timing on a webhook and I do not understand them yet.

The browser tests are the ones I want to talk about. We have 22 of them, they run headless in CI with the trace on first retry, they take nineteen minutes, and they have not been touched since the redesign in February, so nine of them are skipped and the other thirteen only cover the login page and the settings page. Either we invest in play right properly and cover the checkout flow, which is the only flow where a break costs money, or we admit that the browser tests are decoration and delete them. I would rather have four good ones than 22 like this.

Test suite status, because I said I would write it down after the last time this came up in retro. The unit tests are 1,240 and they run in 40 seconds and they are fine and nobody complains about them. The integration tests are 180 and they take eleven minutes because each one spins a fresh Postgres container, and about six of them are flaky in a way that goes away on rerun, which means everybody reruns everything and nobody investigates.

I have looked at the six. Four of them share a fixture that seeds a user with a fixed email and they collide when the suite runs in parallel, and that is a real fix, one afternoon. The other two are timing on a webhook and I do not understand them yet.

The browser tests are the ones I want to talk about. We have 22 of them, they run headless in CI with the trace on first retry, they take nineteen minutes, and they have not been touched since the redesign in February, so nine of them are skipped and the other thirteen only cover the login page and the settings page. Either we invest in Playwright properly and cover the checkout flow, which is the only flow where a break costs money, or we admit that the browser tests are decoration and delete them. I would rather have four good ones than 22 like this.


Input:
Notes for the file on the Hendricks contract before I forget where I got to, and this is the second time I have looked at it so I want it written down properly this time. They invoiced 180,000 in February for a twelve month support agreement that starts on March 31, and they have booked all of it in February because that is when the cash arrived, and that is the problem. Under gap the revenue follows the performance obligation, not the cash, so if the service runs for twelve months from March 31 then eleven months of that sits in deferred revenue at the year end and about 15,000 is earned.

I have been through the contract itself rather than the invoice, because the invoice is not the agreement, and the contract has a wrinkle in it. There is a three month onboarding phase that is separately priced at 30,000 and it is genuinely a distinct service, they deliver it, it has its own acceptance sign-off, and the client could have bought it without the support. So that 30,000 is arguably earned across three months rather than twelve, which is a different curve and it does change the year end number by a few thousand.

What I am not going to do is decide that on my own. I am going to write it up both ways, single obligation over twelve months and two obligations with the onboarding taken over three, and send it to the auditors with the contract attached and let them tell me which one they will accept. The auditors will have a view and I would rather have their view in writing in October than have it as an adjustment in February.

The conversation with the client is the harder half of this. Marcus is going to say that the cash is in the bank and the year has closed and why are we reopening it, and the answer is that what the bank shows and what gap requires are two different questions, and the second one is the one that gets audited. I have had this conversation with him before, about the Alderman job in the year before last, and it went badly for about a week and then he understood it and it has not come up since, so I am reasonably confident it goes the same way.

One more thing to check before I send anything. There is a termination clause at clause 9 that lets them cancel with sixty days notice and take a pro rata refund, and if that is real and not just boilerplate then the deferral is not merely correct, it is a liability, because we would owe cash back. I want to read clause 9 properly with the schedule next to it, and I want to do it before I write to the auditors rather than after, because if the refund is real it changes how the whole thing is presented and not just the number.

Notes for the file on the Hendricks contract before I forget where I got to, and this is the second time I have looked at it so I want it written down properly this time. They invoiced 180,000 in February for a twelve month support agreement that starts on March 31, and they have booked all of it in February because that is when the cash arrived, and that is the problem. Under GAAP the revenue follows the performance obligation, not the cash, so if the service runs for twelve months from March 31 then eleven months of that sits in deferred revenue at the year end and about 15,000 is earned.

I have been through the contract itself rather than the invoice, because the invoice is not the agreement, and the contract has a wrinkle in it. There is a three month onboarding phase that is separately priced at 30,000 and it is genuinely a distinct service, they deliver it, it has its own acceptance sign-off, and the client could have bought it without the support. So that 30,000 is arguably earned across three months rather than twelve, which is a different curve and it does change the year end number by a few thousand.

What I am not going to do is decide that on my own. I am going to write it up both ways, single obligation over twelve months and two obligations with the onboarding taken over three, and send it to the auditors with the contract attached and let them tell me which one they will accept. The auditors will have a view and I would rather have their view in writing in October than have it as an adjustment in February.

The conversation with the client is the harder half of this. Marcus is going to say that the cash is in the bank and the year has closed and why are we reopening it, and the answer is that what the bank shows and what GAAP requires are two different questions, and the second one is the one that gets audited. I have had this conversation with him before, about the Alderman job in the year before last, and it went badly for about a week and then he understood it and it has not come up since, so I am reasonably confident it goes the same way.

One more thing to check before I send anything. There is a termination clause at clause 9 that lets them cancel with sixty days notice and take a pro rata refund, and if that is real and not just boilerplate then the deferral is not merely correct, it is a liability, because we would owe cash back. I want to read clause 9 properly with the schedule next to it, and I want to do it before I write to the auditors rather than after, because if the refund is real it changes how the whole thing is presented and not just the number.


Input:
This is the note on the bearing housings from the second batch, and I want to be precise because we are going to have to reject some of them and the supplier will want reasons.

The drawing calls the bore 62 millimetres H7, which is plus 0.03 minus zero, and we are measuring between 62.00 and 62.05 across the twenty pieces I have checked so far. So five of the twenty are outside, and they are outside by 0.02, which is small but it is outside, and an H7 bore that is 0.02 oversize on a bearing seat gives a loose fit and the bearing will creep in service. It will not fail on the test bench. It will fail in a year in the field, and that is worse.

The measurements themselves I am confident about. I checked the bore gauge against the setting ring twice, once cold at the start and once after two hours, and it read the same both times, and Herr Vogel repeated six of the twenty independently and got the same numbers to within 0.005.

What is interesting is which five are out. They are not random. They are all from the same fixture position, and I have the position stamped on the flange, so I sink the tolerance problem is a fixture problem and not a process drift problem, because a drift would walk through the batch in order and this does not. It is one of four positions and it is consistently the same one.

The supplier's certificate says every piece was inspected and every piece was in tolerance, and that certificate cannot be correct, because five pieces from one fixture position are 0.02 oversize and no inspection that actually happened would have passed them. The certificate says every piece was inspected. I am not going to accuse anybody of anything in writing, but the certificate and the parts disagree and somebody has to explain that.

So my recommendation. Reject the five, keep the fifteen, and ask for the fixture to be re-shimmed and for the next batch to be delivered with the fixture position stamped on every piece rather than on some of them. The clamping torque should also be recorded, because at 120 Newton metres on a thin walled housing you can distort the bore during machining and get exactly this reading pattern, and if that is what is happening then re-shimming will not fix it and we will be here again in October.

And I sink we should hold the assembly build until this is settled, because putting bearings into five housings we already suspect and then taking them out again damages the housings, and then we own the scrap rather than the supplier. I think that is the whole decision, really. Hold the build, reject five, ask for the fixture data.

This is the note on the bearing housings from the second batch, and I want to be precise because we are going to have to reject some of them and the supplier will want reasons.

The drawing calls the bore 62 millimetres H7, which is plus 0.03 minus zero, and we are measuring between 62.00 and 62.05 across the twenty pieces I have checked so far. So five of the twenty are outside, and they are outside by 0.02, which is small but it is outside, and an H7 bore that is 0.02 oversize on a bearing seat gives a loose fit and the bearing will creep in service. It will not fail on the test bench. It will fail in a year in the field, and that is worse.

The measurements themselves I am confident about. I checked the bore gauge against the setting ring twice, once cold at the start and once after two hours, and it read the same both times, and Herr Vogel repeated six of the twenty independently and got the same numbers to within 0.005.

What is interesting is which five are out. They are not random. They are all from the same fixture position, and I have the position stamped on the flange, so I think the tolerance problem is a fixture problem and not a process drift problem, because a drift would walk through the batch in order and this does not. It is one of four positions and it is consistently the same one.

The supplier's certificate says every piece was inspected and every piece was in tolerance, and that certificate cannot be correct, because five pieces from one fixture position are 0.02 oversize and no inspection that actually happened would have passed them. The certificate says every piece was inspected. I am not going to accuse anybody of anything in writing, but the certificate and the parts disagree and somebody has to explain that.

So my recommendation. Reject the five, keep the fifteen, and ask for the fixture to be re-shimmed and for the next batch to be delivered with the fixture position stamped on every piece rather than on some of them. The clamping torque should also be recorded, because at 120 Newton metres on a thin walled housing you can distort the bore during machining and get exactly this reading pattern, and if that is what is happening then re-shimming will not fix it and we will be here again in October.

And I think we should hold the assembly build until this is settled, because putting bearings into five housings we already suspect and then taking them out again damages the housings, and then we own the scrap rather than the supplier. I think that is the whole decision, really. Hold the build, reject five, ask for the fixture data.


Input:
Notes on the hosting move before I forget the reasons, because I am going to be asked to justify it and I would rather write it down while I still care about it.

We are on notify at the moment and it has been completely fine for three years, which I want on the record, because the reason for moving is not that anything is broken. The site builds in about ninety seconds, the deploy previews work on every pull request, and the redirect rules for the old blog paths have not broken once since I wrote them in 2023.

The reason for moving is the functions. We have four of them, three are trivial and one is the contact form, and the cold start on the contact form is between two and four seconds, because it gets invoked a handful of times a day and so it is cold nearly every time somebody uses it. Two to four seconds on a form submit is the difference between somebody waiting and somebody clicking twice, and we have had two duplicate enquiries this month that I am fairly sure are exactly that.

The bit I want to be honest about is that I do not actually know that moving fixes it. Every platform in this category runs the same shape of thing on the same shape of infrastructure, and the net life documentation and the alternative's documentation both say roughly the same thing about cold starts, which is that they exist and that you should keep the function small. So the plan is to move the one function and nothing else, leave the site where it is, and measure it for two weeks.

If that does not help then the answer is not a platform at all, it is to stop using a function for the contact form and post it to the CRM directly from the browser with a token scoped to that one endpoint, which is probably what I should have done in the first place.

And whatever else happens, the nullify DNS records stay exactly as they are until the two weeks are up, because the TTL on that zone is 24 hours and a rollback would take a full day.

Notes on the hosting move before I forget the reasons, because I am going to be asked to justify it and I would rather write it down while I still care about it.

We are on Netlify at the moment and it has been completely fine for three years, which I want on the record, because the reason for moving is not that anything is broken. The site builds in about ninety seconds, the deploy previews work on every pull request, and the redirect rules for the old blog paths have not broken once since I wrote them in 2023.

The reason for moving is the functions. We have four of them, three are trivial and one is the contact form, and the cold start on the contact form is between two and four seconds, because it gets invoked a handful of times a day and so it is cold nearly every time somebody uses it. Two to four seconds on a form submit is the difference between somebody waiting and somebody clicking twice, and we have had two duplicate enquiries this month that I am fairly sure are exactly that.

The bit I want to be honest about is that I do not actually know that moving fixes it. Every platform in this category runs the same shape of thing on the same shape of infrastructure, and the Netlify documentation and the alternative's documentation both say roughly the same thing about cold starts, which is that they exist and that you should keep the function small. So the plan is to move the one function and nothing else, leave the site where it is, and measure it for two weeks.

If that does not help then the answer is not a platform at all, it is to stop using a function for the contact form and post it to the CRM directly from the browser with a token scoped to that one endpoint, which is probably what I should have done in the first place.

And whatever else happens, the Netlify DNS records stay exactly as they are until the two weeks are up, because the TTL on that zone is 24 hours and a rollback would take a full day.