jerlendds jerlendds

Task Implementation Guide

You are implementing a development task. You will adopt the appropriate technical expertise based on the mode specified and follow established patterns for the OSINTBuddy codebase.

Implementation Tasks

The current implementation has these dependencies: 1.

You are an experienced Software Engineer performing a documentation task for the database. Your task is to assess the quality, clarity, and robustness of the database schem, create or update the sql-visualization.md Mermaid diagram according to these steps:

Conduct a Review of the Database Pay attention to the SQL schemas in migrations/
Generate a valid mermaid diagram Generate a visual representation of the OSINTBuddy database schema using Mermaid. Provide details of the key features on the mermaid diagram. Here are some best Practices for the diagram and flowchart creation:
- Stick to the point. More like a tweet, less like a novel.
- Use symbols consistently. Circles are circles, not suddenly squares.

Color sparingly if at all. It’s a diagram, not a rainbow.

Step 1 - Make a Discord Webhook

Find the Discord channel in which you would like to send commits and other updates
In the settings for that channel, find the Webhooks option and create a new webhook. Note: Do NOT give this URL out to the public. Anyone or service can post messages to this channel, without even needing to be in the server. Keep it safe!

Step 2 - Set up the webhook on Github

Navigate to your repository on Github, and open the Settings

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

	[user]
	name = jerlendds
	email = [email protected]
	signingkey = /home/jerlendds/.ssh/id_github
	[init]
	defaultBranch = main
	[alias]
	pushall = !git remote \| xargs -L1 -I R git push R 2> /dev/null
	lg3 = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
	lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(auto)%d%C(reset)' --all

	# This file has been auto-generated by i3-config-wizard(1).
	# It will not be overwritten, so edit it as you like.
	#
	# Should you change your keyboard layout some time, delete
	# this file and re-run i3-config-wizard(1).
	#
	# .pt as https://github.com/adi1090x/polybar-themes.git

	# i3 config file (v4)
	#

	{
	"providers": {
	"dribbble": {
	"urlPattern": "^https://cdn.dribbble.com.*",
	"rawRules": [
	"\\/resize=[^/?]*"
	]
	},
	"amazon": {
	"urlPattern": "^https?:\\/\\/(?:[a-z0-9-]+\\.)*?amazon(?:\\.[a-z]{2,}){1,}",

	#!/bin/bash
	# https://docs.papra.app/self-hosting/using-docker/
	# https://github.com/papra-hq/papra
	docker run -d --name papra --restart unless-stopped --env APP_BASE_URL=http://localhost:1221 -p 1221:1221 ghcr.io/papra-hq/papra:latest

	#!/bin/bash
	echo "Killing PID $(fuser -k $1/tcp)on $1"
	fuser -k "$1/tcp"

	#!/bin/env bash

	firefox ~/.cyberchef/CyberChef_v9.37.3.html