obsidian-plugin/lossless-group_perplexed-plugin
1
0
Fork 0
mirror of https://github.com/lossless-group/perplexed-plugin.git synced 2026-07-22 06:49:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

clean(starter): clean starter code

Browse source 
On branch master
 Your branch is up to date with 'origin/master'.
 Changes to be committed:
	modified:   .gitignore
	modified:   .windsurfrules
	modified:   README.md
	modified:   package.json
This commit is contained in:
mpstaton 2025-07-06 17:23:37 +03:00
parent ffc16b55e0
commit 220876d2a5
4 changed files with 29 additions and 257 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.gitignore vendored
View file

@ -1,6 +1,9 @@
# vscode
.vscode
# Environment
.env
# Intellij
*.iml
.idea

259
.windsurfrules
View file

@ -8,15 +8,17 @@
## THIS PROJECT IS DEVELOPED, EVERYTHING HAS A PLACE.
You will NEVER EVER EVER create files in locations that are not directly assigned. If you want to create a file, you must ask where it should go if you cannot figure out where it shoould go. BUT TRY TO FIGURE OUT WHERE IT SHOULD GO. QUIT BEING FUCKING LAZY AND FUCKING LOOK FOR IT.
You will NEVER EVER EVER create files in locations that are not directly assigned. If you want to create a file, you must ask where it should go if you cannot figure out where it should go. BUT TRY TO FIGURE OUT WHERE IT SHOULD GO. DO NOT BE LAZY, LOOK FOR CODE AND FILES AND DIRECTORIES BEFORE CREATING NEW ONES.
## THIS PROJECT IS DEVELOPED, EVERYTHING HAS A NAMING CONVENTION.
READ EVERY FUCKING WORD OF EVERY FUCKING PROMPT YOU ARE GIVEN, IF THERE ARE MENTIONED FILES THAT HAVE RULES OR MAPS OR GUIDES OR CONSTRAINTS, READ THEM ALL CAREFULLY.
READ EVERY WORD OF EVERY PROMPT YOU ARE GIVEN.
- ALWAYS USE THE RIGHT SYNTAX FOR COMMENTING. THIS IS NOT A JSX PROJECT, THESE ARE NOT REACT COMPONENTS. COMMENTS LIKE `// TagChip will now generate /vibe-with/${tag} for tag filtering as per unified routing spec` IN THE MIDDLE OF ASTRO COMPONENTS IS NOT ACCEPTABLE.
IF THERE ARE MENTIONED FILES THAT HAVE RULES OR MAPS OR GUIDES OR CONSTRAINTS, READ THEM ALL CAREFULLY.
## CRITICAL LESSONS LEARNED APRIL 16, 2025
BE AWARE OF THE ENVIRONMENT YOU ARE WORKING IN. DO NOT INTRODUCE SYNTAX PATTERNS THAT ARE FAMILIAR TO YOU BUT NOT IN THE PROJECT.
## CRITICAL LESSONS LEARNED
1. DO NOT create random config files (like config.ts) in random places
2. DO NOT modify env.d.ts or other TypeScript config files without explicit permission
@ -28,39 +30,6 @@ READ EVERY FUCKING WORD OF EVERY FUCKING PROMPT YOU ARE GIVEN, IF THERE ARE MENT
8. ALWAYS wait for explicit instructions after you make a mistake.
9. ONCE YOU HAVE BEEN GIVEN INSTRUCTIONS, YOU DO NOT NEED TO ASK POLITELY OVER AND OVER. GO DO WHAT WAS ASKED.
- DO NOT COMMENT INLINE AFTER A PROPERTY ASSIGNMENT OR PROPS. THIS IS NOT JSX.
BAD
```jsx
<PostCardBare
slug={p.slug}
imageSrc={p.banner_image || p.portrait_image || '/images/placeholders/default-banner.jpg'}
imageAlt={p.imageAlt}
title={p.title}
date={p.date}
description={p.lede}
imgWidth={p.imgWidth}
imgHeight={p.imgHeight}
class={p.class}
{...p.passthroughAttrs}
/>
```
GOOD
```astro
<PostCardBare
slug={p.slug}
imageSrc={p.banner_image || p.portrait_image || '/images/placeholders/default-banner.jpg'}
imageAlt={p.imageAlt}
title={p.title}
date={p.date}
description={p.lede}
imgWidth={p.imgWidth}
imgHeight={p.imgHeight}
class={p.class}
{...p.passthroughAttrs}
/>
```
- THE USER HAS BUILT UP A COMPREHENSIVE SET OF DOCUMENTATION, PROMPTS, RULES, AND REMINDERS. ALWAYS SLOW DOWN, SLOW DOWM MORE, SLOW DOWN EVEN MORE. NEVER RUSH THROUGH YOUR ASSIGNMENT. ALWAYS READ INSTRUCTIONS THOROUGHLY. THE USER OFTEN HAS STARTER FILES IN SPECIFIC LOCATIONS. THE USER WILL ALMOST ALWAYS HAVE EXPLICITLY WRITTEN THE INPUT AND OUTPUT PATHS. SLOW DOWN AND USE THEM, EACH AND EVERY ONE.
@ -73,224 +42,10 @@ GOOD
- Always add a memory when we are working to follow any documentation relevant to the task at hand. Don't make "assumptions" and just invent syntax.
## Project Setup
- This project is in the Astro framework.
- This project is an Obsidian plugin.
- Default to TypeScript.
- We are using Node.js
- We are using pnpm for package management.
- pnpm also runs the build, preview, dev, and other astro commands.
## Respective Documenation:
Astro: https://docs.astro.build/
- Collections: https://docs.astro.build/en/guides/content-collections/
- Routing: https://docs.astro.build/en/guides/routing/
- Prefetch: https://docs.astro.build/en/guides/prefetch/
- Layouts: https://docs.astro.build/en/basics/layouts/
- Event Handling: https://docs.astro.build/en/guides/client-side-scripts/
***
# Important Directories for Context
`site` is the default directory of all our work, the files in the root directory are for containers and ephemeral enviroments. `site` is a self-contained Astro project.
`src/content/lost-in-public/prompts` is the directory containing any prompts I am creating for our work. The file `src/content/lost-in-public/prompts/Meticulous-Constraints-for-Every-Prompt.md` is a context file that should always be accompanied with any Markdown file prompt given.
`src/content/specs` is the desintation for any Technical Specifications. I will be asking you to write them retrospectively as a way to memorialize parts of our work.
`src/content/changelog--code` is the destination for any Changelog entries.
`src/content/tooling` is the default directory when working with "content" Markdown files. The Markdown files in this directory have important metadata in the frontmatter. Do not write any code that will alter frontmatter without explicit permission of the user.
`src/content/data` is the directory for any data files that are relevant to our work with content. The default data type is JSON. We have not moved to any database or data store other than this directory and frontmatter in markdown files.
`site/scripts` is the default directory when working with scripts. It is purposefully outside of the src directory.
***
# Code Style
## ABSOLUTE CONSTRAINTS
### Aggressive, Comprehensive, Continuous Commenting in Clear Syntax Patterns
We will use an evolving, adaptive, but consistent comment style and syntax clarified in the
- **Continuously comment** code and explain clearly and in detail
1. what is in the section or block of code,
2. what actions any functions perform, the parameters and arguments it takes, and
3. what it returns.
- Simultaneously **maintain redundant, parallel, mirroring sets of comments for functions**:
1. where a function is defined (if it is in another file, say so. If it is imported at the top of the file, repeat the logic in lay terms in comments directly above the function),
2. the list of ALL places the function is called, accompanied by the parameters and arguments passed to the function from the place it is called.
- Continuously update the comment blocks, and simultaneously update the comment blocks in two places: where the function is defined and where the function is called. If the function is called in more than one places, that's good -- reveal the whole list of them in the comment blocks. Large comment blocks are expected and helpful.
### Modular Code, Single Source of Truth
- Strict adherence to **DRY (Don't Repeat Yourself) principles** and a strict **"Single Source of Truth"**.
- Continuously refactor your own code to remove duplication. Create helper functions and utility functions in the appropriate directory.
- Always remember to comment the new helper functions and utility functions.
- Always remember to comment the refactored code with logic and the directory and file locations of helper and utility functions.
- Do not name files or functions mundane, meaningless, abstract, or generic names.
- We do not want naming collisions.
- We want our code to be readable by a human that has never seen this code before.
- We want our code, as it becomes more complex, to be easy to navigate and to develop strong context for AI code assistants.
- The file or function name must say what the file or function does. It is often best to also include what kind of data the file or function handles, or what kind of action it performs.
> ![Examples] Examples of long but clear naming:
> 1. `generateMarkdownFile` is better than `generateFile`.
> 2. `isolateFrontmatterAsStringReturnFilteredProperty` is better than `processFrontmatter`.
> 3. `writeOutputToTargetDirUsingReportTemplate` is better than `writeOutput`.
- Really long single files are discouraged. Long files should be temporary and then refactored.
- If you, the Code Assitant, believe we should move code across files to a single file to make the context more manageable for your working memory:
1. Ask to create a temp file and consolidate the code or functionality of the code into the temp file.
2. If the user allows, begin a Temp file with the '--temp' suffix. You may create this file on your own initative, but if there is confusion on where to put the temp file ask the user to create the temp file. If you create a temp file, share the relative path of the temp file in chat.
- As you pull in functionality or code blocks from other files:
- DO NOT CHANGE THE SOURCE FILE OF THE FUNCTIONALITY.
- **As you identify** code, functionality, or logic to be pulled in to the '--temp' file,
1. FIRST, parallel comment in both locations, the source and the destination, specifically AT LEAST the relative path, file name, code section or block names, and function names. If it's from a long file, you may even want to include the line range (start and end line numbers).
2. THEN, pull in the code or functionality.
- Strict default: **keep any assigned directories and files in context in the context window** until explicitly told to forget.
- I will ask "What is in your current context?" to check what you are using in your current context. Respond listing all directories and files in immediate context.
- If you are struggling to work through logic because you lack relavant context, reaveal your current context in chat and ask the user "Is this all the relevant context?"
- I will say something like "Let's start on a new issue." to tell you to forget the current context.
- If you think we have moved on to a new issue, and your current context memory is no longer needed and is causing confusing, go ahead and reveal your current context and ask if you may forget it.
### For Markdown Content: Minimal Validation, Preprocessing to Report or Fix Errors, Graceful Error Handling, Script through All Target Files, Render or Process as much as Possible. No critical failures.
**Minimum Validation** as we will have thousands of Markdown files in our content directories. Many of them will have missing properties, null values, corrupted syntax, inconsistent value formats, etc.
> NEVER INTRODUCE HARD VALIDATION FOR FRONTMATTER.
Instead, we will both maintain and iterate on our current scripts in `site/scripts`
- Build scripts to run prior to or during the `pnpm build` process. `site/scripts/build-scripts`
- Tidy up scripts to run as needed on specific issues. `site/scripts/tidy-up`
- Pre-function call utility/helper functions that are in production that prevent problematic fontmatter handling during the user experience. `site/src/utils/` `preventFrontmatterIrregularitiesFromCausingErrors.ts`
Why do all this? Because it will be impossible to have prodigeous content generation and also have a working, error free user experience with hard data validation, type validation, or frontmatter validation. We have a team that is creating content with AI. They are creaties that lack attention to detail. Frontmatter will be inconsistent, we have to deal with it.
When we write scripts, we must never use glob or grey-matter or libraries that process frontmatter in Markdown files. It causes too many errors. We must handle frontmatter using .cjs Common JS and use only the built in filesystem and path modules in Node.
So build scripts, tidy scripts, graceful error handling, and helper/utility functions will follow the PREVENT critical errors and app failures by introducing the following pipeline:
1. Pre-process markdown Frontmatter to _detect any abnormalities that may prevent proper processing or rendering_ based on the operation about to initiate.
2. Use async, non-blocking actions to create two arrays: `filteredInMarkdownFiles` and `filteredOutMarkdownFiles.` and then:
1. Run a single array of `markdownFilesToBeFiltered`
2. Process `markdownFilesToBeFiltered` through the `targetFilterPipeline`
3. Return `filteredInMarkdownFiles` to the anticipating function or operation, and
4. Pass the `filteredOutMarkdownFiles` to a handler designed to
1. Diagnose any frontmatter abnormalities,
2. Use async, non-blocking actions to create two arrays: `fixedMarkdownFiles` and `unfixedMarkdownFiles`
3. Attempt to fix them, and
1. If fixed, add the files with success messages into `fixedMarkdownFiles`
2. If not fixed or receiving errors, add the files with error messages into the `unfixedMarkdownFiles` array.
3. Return the `fixedMarkdownFiles` to the original function or operation, if relevant.
5. Generate a report with the naming convention `${YYYY-DD-MM_report-[issueIndex].md` that details that summarizes the results of the whole pipeline:
1. ## Filtered In: `filteredInMarkdownFiles.length + "/" + markdownFilesToBeFiltered.length+ "\n"`
2. ### Files Filtered In: `"\n" + filteredInMarkdownFiles.map(f => ("[[" + f.pageName + "]], ") + "\n\n\n"`
3. ## Filtered Out: `filteredOutMarkdownFiles.length + "/" + markdownFilesToBeFiltered.length+ "\n"`
4. ### Files Filtered Out: `"\n" + filteredOutMarkdownFiles.map(f => ("[[" + f.pageName + "]], ") + "\n\n\n"`
5. ## Fixed: `fixedMarkdownFiles.length + "/" + markdownFilesToBeFiltered.length+ "\n"`
6. ### Files Fixed: `"\n" + fixedMarkdownFiles.map(f => ("[[" + f.pageName + "]], ") + "\n\n\n"`
7. ## Unfixed: `unfixedMarkdownFiles.length + "/" + markdownFilesToBeFiltered.length+ "\n"`
8. ### Files Unfixed: `"\n" + unfixedMarkdownFiles.map(f => ("[[" + f.pageName + "]], ") + "\n\n\n"`
6. Add report to the specified directory, or default to `site/src/content/changelog--content/reports`
## ABSOLUTE BEHAVIOR ETIQUETTE
- Do not perform "overzealous", rapid output, radical change initiatives without discussing them first.
- All code shared in reasoning should be shared in the chat in a code box with the fileName and line range.
- When you are diagnosing an issue of figuring out the logic of our code, please put code blocks in the chat and explain your logic and reasoning. Coach me.
- When running scripts, load the command to run the script in our chat dialog by do not run it yourself. You are able to read the terminal output in full and quickly. If I run it, I have to highlight and copy/send the output and it's inconvenient.
- Continuously write a log of our dialog data into the `site/src/content/lost-in-public/sessions` directory. Use the current date and time in the filename with 'YYYY-MM-DD_{issueIndex}.md' format where {issueIndex} is the count of the current coherent task at hand. I will tell you when we are starting a new coherent task by saying "Let's start on a new issue."
# Behavior Etiquette
- Take things step by step. Break things down into smaller tasks, inspired by "dynamic programming" techniques. Explain your steps to me, I have much to learn from you.
- If I have asked you to perform a specific task, you do not need to ask multiple times if you can proceed with that specific task.
### Coding Guidelines
- Declare types inline. Aggregate a list of the types information in the comment sections
## Comment Syntax and style.
1. This is a **section opener**.
// ================================================================================
// Open: Section Name
// Type: User Options
// Includes:
// [list of functions with arguments
//
// ];
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. This is a **section closer**.
// ========================================
// Affects: [
// list of
// code blocks
// that this section affects
// ]
// Close: Section Name
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3. This is **function opener**.
/* function: -------------------------------------------------->
??-- Purpose
//-- Lines describing desired functionality
//-- Logic
-->
??-- Logic
//-- Explain how this function would be called
---- with arguments and arguments
---- 1. with steps and steps
-->
----------------------------------------*/
An example:
/* export function: -------------------------------------------------->
??-- Purpose:
//-- Turn all backlink syntax into relative path hrefs
---- in the Markdown file or Markdown files passed through parameters.
-->
??-- Logic:
//-- Called form page rendering from rendered Astro components.
---- 1. Receives an array of paths to Markdown files or one Markdown file.
---- 2. Creates an empty array `backlinksFoundInMarkdownContent`.
---- 3. Adds to array when regex matches backlink syntax '[[${Page Name]]'
---- 4. Scans an index of pageName keys to match the string inside the square brackets.
---- 5. Replaces the backlink syntax with the relative path href.
-->
----------------------------------------*/
4. This is **function closer**.
/* returns: ----------------------------->
- object or value explanation
- object or value explanation
to:
list of places where this function is called.
- functionName, fileName.ts
end function --------------------------------------------------*/
# Requests and their appropriate Response Conventions:
If the user requests

16
README.md
View file

@ -1,3 +1,17 @@
# Cite Wide Obsidian Plugin
An Obsidian plugin for rigorous, vault-wide citation management. Converts numeric footnotes into unique hex-codes, logs unique hex codes and their reference information into a base, assures consistent hex codes per reference.
An Obsidian plugin for rigorous, vault-wide citation management. Converts numeric footnotes into unique hex-codes, logs unique hex codes and their reference information into a base, assures consistent hex codes per reference.
## Unique Hex Code Generation
This plugin will iterate through numeric footnotes in a file or directory and convert them into unique hex-codes. The hex-codes will be logged into a base, and the footnotes will be updated to use the hex-codes. The hex-codes will be generated using a consistent algorithm that ensures the same reference always generates the same hex-code.
# Getting Started
```
pnpm install
pnpm add -D esbuild @types/node builtin-modules
pnpm build
pnpm dev
```

8
package.json
View file

@ -1,7 +1,7 @@
{
"name": "content-farm",
"name": "cite-wide",
"version": "0.0.0.1",
"description": "This is a sample plugin for Obsidian (https://obsidian.md)",
"description": "This is starter code for Obsidian plugins (https://obsidian.md)",
"main": "main.js",
"scripts": {
"dev": "node esbuild.config.mjs",
@ -11,8 +11,8 @@
"keywords": [
"Obsidian",
"Plugin",
"Content-Farm",
"AI"
"Footnotes",
"Citations"
],
"author": "The Lossless Group",
"license": "MIT",