This time i added the display , fixed the problematic pcb , wrote the base firmware also made the holes on the bosses to mount the pcb

Finally after the review , completely redesigned the whole thing , made the pcb smaller ,made the 3d box smaller too . Also estimated the price in jlcpcb to get the pcb its hella 3.51$‘s now i think i need to write firmware but before tht i havent made any holes on the cad’s mounting portion(i mean where the pcb and the esp is screwed), after i get it in hannd , i ma gonna do tht manually , it will be more helpful .

This time i fixed the session issue and wrote THE README MYSELF ,took me a lot of time still worth it

Finally session based metadata added now i can sleep in ease also it is v3.1.1 both on crates and github

Finally fixed the issue with imported .step and made my own cuboid screw mount now its finally worth it.

Finally after a lot of work , i managed to design the cad case , but still i came to know this one has the screw socket size mismatch , i will fix tht and designing stage finished

i removed the resistors that i intended to use for pulling down as i came to see the official guide use the built in ones , i though why me? and removed those , also placed the switches with more precision and estimated the cost will be 10$ , perfect for the given budget now imma gonna do the cad

today i build the schematic and the pcb for init_dawn.d , it took me likely 3hr and 30 minute but due to some lapse problem i cant sync it , anyway i added only 7 physical switches because i dont need 12 , i used 5 gpio pins for the 7 switches , i have a proper idea to control them by using separate mode , 1: Configurable mode
2: Alarm mode
i mean when config mode , the bottom 5 switch will work and when alarm mode only upper two . Also the bottom right is kinda a shift switch , to change +/- for hour and minutes etc , its still a draft but the idea looks clean.

This is probably the most hardcore devlog in this whole session, my task was simply write debug , ask gpt why it didnt work , then deepseek wrote code still didnt work and thts how 7 hrs passed me adding session with persistent memory also with a lot of optimizations , also v3.1.0 is on cargo now , go ahead and check it up for me uWu.

This time it is a huge improvement , it looks like v3 to v3.0.1 but i added pyo3 and python api’s , i mean now even python can use my rust package with rust like speed + safety in python , also i fixed some small bugs in extractor , also added benchmarks (the speed is insane , see on the tagged screenshot ) also the ml is hella fast , in python the ml model only took 3x time than a whole iteration in rust with extractors and pyo3 overhead , also now i have got some more ideas to add in my hbp100 i think those will make it even better and polished..

today finally i shipped hbp100 v3 on crates “https://crates.io/crates/hbp100/3.0.0” , this time no python runtime full rust even ml in rust thx to lightgbm3 , now it is far faster than the python pkl one , it took me 3+hrs just to train the model and to convert my old python logic into rust , then i had to do the dual readme setup to prevent the bug i came to meet on my last project too , now its fine i made a release on github too , in the crates release there is no “test.rs” but in git release i added tht , the tagged screenshot is result of test

actually when i started the project i didnt knew abt stardance , still after v2.2 i used it , v2.2 was pure python and really fast but still it didnt convince me , so i went to v3 rust and i tried rust and python hybrid it sucked i am unable to debug the mess i made so i am thinking to write the ml portion in rust too , i have a live website for v2.2 too , i am new to onnx so it might take some time debugging , still my v2.2 was pretty much successful , one can try tht on “https://github.com/Erox-02/humming-bird-v3/releases/tag/v2.0.0” , so next will be v3.0 and i intend to ship the live website as a other project

after the version hell , i added -R feature just like yay , now it looks better and to be honest the llm is unpredictable i genuinely advise to use the fallback model its fine for most cases .

I have successfully built aurek 2.1.3 , after treating some hillarious bugs , its finally here. try it now on
“https://crates.io/crates/aurek” i found i literally did the same mistake(as v1) ,naming on crates(cargo) requires README.md and on stardance readme.md , i have decided to keep both from now also there were some other bug fix and qol , after the major v2 , for last 3 hrs i have added llm response , a config file on /etc/aurek.conf (yeah here i accidentally added my /home/erox/.config) so main change , added some more bugs to fix later , sank you

Aurek v2.0.0 is probably the biggest change the project has had so far. aurek started as a small security wrapper for yay that checks aur packages before installation, mainly using heuristics to look for things like remote script execution, suspicious sudo usage, dangerous commands, chmod 777, base64, eval and other patterns that could be risky inside a pkgbuild. The problem with heuristics is that they only really see patterns, they don’t understand much context, so v2.0.0 adds optional local LLM analysis using Gemma through llama.cpp. Everything runs locally, no external API or internet connection is needed, and aurek handles starting llama-server, waiting for it, running the analysis and shutting it down afterwards. The LLM is meant to be another layer on top of the heuristics, not a replacement for them. v2.0.0 also added Git fallback when the aur API isn’t available and improved some of the package handling. Colored terminal output isn’t actually part of v2.0.0, that’s being worked on for v2.1.0 along with some other improvements. After publishing v2.0.0, a small packaging issue was noticed where the README was named readme.md instead of README.md, which meant crates.io didn’t display it properly. Because of that v2.0.0 was yanked and v2.0.1 was released with the filename fixed, with no actual code or functionality changes. The project itself has been moving along for a while before Stardance too. The v1 devlog couldn’t be published because I wasn’t registered on Stardance(my aadhar was on queue ) at the time, but development kept going and Hackatime picked up on the continued work. So instead of leaving that part undocumented, all three stages are being put together here — v1, v2.0.0 and the small v2.0.1 fix. The next plans are more LLM models, better heuristics, recursive dependency scanning and eventually support for package managers beyond the aur. aurek is still meant to be a security layer, not a guarantee that every package is safe, but the goal is to make checking aur packages a bit less of a just trust this pkgbuild and pray situation.