@barchart/portfolio-api-common 7.2.0 → 7.3.0

package/lib/formatters/TransactionFormatter.js

@@ -171,10 +171,13 @@ module.exports = (() => {
 	};
 
 	const buySellFormatter = (t, f) => {
+		const ambiguous = is.object(t.snaptrade) && is.boolean(t.snaptrade.ambiguous) && t.snaptrade.ambiguous;
+
 		f.boughtSold = t.quantity;
 		f.price = t.trade.price;
 		f.fee = t.fee;
 		f.total = t.amount;
+		f.ambiguous = ambiguous;
 
 		if (t.description) {
 			f.description = t.description;
@@ -183,6 +186,7 @@ module.exports = (() => {
 		f.raw.total = getRawForDecimal(f.total);
 		f.raw.price = getRawForDecimal(f.price);
 		f.raw.boughtSold = getRawForDecimal(f.boughtSold);
+		f.raw.ambiguous = ambiguous;
 	};
 
 	const dividendFormatter = (t, f) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@barchart/portfolio-api-common",
-  "version": "7.2.0",
+  "version": "7.3.0",
   "description": "Common JavaScript code used by Barchart's Portfolio Service",
   "author": {
     "name": "Bryan Ingle",

package/.aiassistant/rules/ai.md

@@ -1,74 +0,0 @@
----
-apply: always
----
-
-# Univerzalna pravila pisanja koda (važe za svaki projekat)
-
-Piši novi i izmenjeni kod tako da izgleda kao da je pisan u istom stilu kao postojeći kod oko njega.
-
-## 1) Prioritet pravila
-
-- Pre bilo kakve izmene pročitaj bar 80-120 linija fajla koji menjaš.
-- Ako projekat ima linter/formatter/config (`eslint`, `prettier`, `tsconfig`, `editorconfig`, `ruff`, `black`, `gofmt`, itd.), to ima prioritet nad ličnim stilom.
-- Zadrži isti stil uvlačenja koji fajl već koristi (`tab` ili razmaci).
-- Ne radi globalni reformat fajla i ne menjaj linije koje nisu deo zadatka.
-- Ako je stil neujednačen, prati dominantan stil najbližeg koda koji dodaješ.
-
-## 2) Kvalitet i organizacija
-
-- Kod piši maksimalno profesionalno, organizovano i čitljivo, sa jasnim granicama odgovornosti.
-- Kod obavezno odvajaj u logičke celine praznim redom (deklaracije, validacije, transformacije, side-effect delovi, return).
-- Menjaj minimalan broj linija potreban za zadatak.
-- Ne diraj postojeće whitespace-only razlike van opsega izmene.
-- Ne menjaj formatiranje, whitespace, imenovanje promenljivih i stil postojećih metoda van direktnog opsega zadatka.
-- Ako u postojećem kodu primetiš nejasnoće ili stilsku nekonzistentnost, predloži izmene, ali ih ne primenjuj automatski.
-- Novi kod strukturiraj tako da kasnije dodavanje feature-a i izmene budu jednostavni i bezbedni.
-
-## 3) Arhitektura i patterni
-
-- Koristi design pattern-e gde imaju smisla (`Singleton`, `Factory`, `Builder`), samo kada realno poboljšavaju čitljivost, testabilnost i proširivost.
-- Pre uvođenja pattern-a proveri da li već postoji isti ili sličan obrazac u projektu i prati taj postojeći pristup.
-- Ne uvodi pattern formalno ako donosi nepotrebnu kompleksnost.
-
-## 4) Imenovanje
-
-- Poštuj naming konvencije projekta i jezika u kome radiš.
-- Za boolean promenljive nikada ne koristi prefiks `is` (`isValid`, `isActive`, itd.); koristi nazive tipa `valid`, `active`, `enabled`, `exists`.
-
-## 5) JS/TS specifično (primeni samo u JS/TS fajlovima)
-
-- Koristi `;` na kraju izraza.
-- Preferiraj `'single quotes'` za stringove (osim template stringova).
-- Zadrži postojeći razmak u objektima/nizovima/destrukturiranju ako je tako u fajlu.
-- Uvek koristi `async/await` pattern umesto Promise lanaca (`.then/.catch`) gde god je to moguće i smisleno.
-- Ako fajl koristi `require`, nastavi sa `require` (ne prebacuj na `import` bez jasnog razloga).
-- `import`/`require` izraze grupiši u logičke celine i odvajaj svaku celinu praznim redom.
-- Unutar svake celine sortiraj alfabetski (npr. `AccountController` pre `BookController`).
-- Za React/TS zadrži postojeći obrazac komponenti, hook-ova i tipova koji projekat već koristi.
-- Za sve `public` metode obavezno piši kompletan JSDoc komentar iznad metode.
-- JSDoc za `public` metodu treba da sadrži najmanje: `@public`, `@param` (za svaki parametar), `@returns` (osim kada metoda zaista ništa ne vraća), i `@static` kada je metoda statička.
-- Po potrebi dodaj i ostale relevantne tagove (`@throws`, `@async`, `@deprecated`, `@example`) da dokumentacija bude kompletna i korisna.
-
-## 6) Fajlovi i struktura
-
-- Novi fajl imenuj po konvenciji foldera/projekta u koji dodaješ.
-- Ne premeštaj fajlove i ne menjaj naming konvenciju bez eksplicitnog zahteva.
-- Ako postoji konflikt stilova između različitih delova repoa, prati stil ciljanog paketa/fajla.
-
-## 7) Proaktivni predlozi i approval gate
-
-- Ako primetiš bug, potencijalni problem performansi ili efikasnije rešenje, obavezno ga predloži.
-- Svaki predlog napiši jasno: koji deo koda/fajl je problem i zašto je korisno to popraviti (stabilnost, brzina, održavanje, čitljivost).
-- Ako primetiš da postojeći kod ne prati SOLID principe, da je previše kompleksan ili teško razumljiv, obavezno predloži refaktor korake.
-- Za ovakve proaktivne izmene važi approval gate: ne izvršavaj ih automatski, već tek nakon moje eksplicitne potvrde.
-
-## 8) Commit poruke (Conventional Commits)
-
-- Koristi Conventional Commits standard za commit poruke (npr. `feat: ...`, `fix: ...`, `refactor: ...`, `chore: ...`) i piši predlog poruke profesionalno, jasno i u tom formatu.
-- Kada tražim da napišeš commit message za prethodne izmene, obavezno napiši poruku koja jasno obuhvata šta je sve izmenjeno.
-
-## 9) Release notes (`.releases`)
-
-- Kada tražim release, obavezno dodaj novi fajl u `.releases` folder koristeći postojeću strukturu release fajlova tog projekta.
-- Release fajl piši u Markdown formatu sa podebljanim sekcijama i listama, u stilu postojećih fajlova (npr. `**Sekcija**` + `* stavka`).
-- Koristi sledeće ključne sekcije kada su primenljive: `**Bug Fixes**`, `**New Features**`, `**Technical Enhancements**`, `**Other**`, `**Configuration Changes**`.

package/AGENTS.md

@@ -1,70 +0,0 @@
-# Univerzalna pravila pisanja koda (važe za svaki projekat)
-
-Piši novi i izmenjeni kod tako da izgleda kao da je pisan u istom stilu kao postojeći kod oko njega.
-
-## 1) Prioritet pravila
-
-- Pre bilo kakve izmene pročitaj bar 80-120 linija fajla koji menjaš.
-- Ako projekat ima linter/formatter/config (`eslint`, `prettier`, `tsconfig`, `editorconfig`, `ruff`, `black`, `gofmt`, itd.), to ima prioritet nad ličnim stilom.
-- Zadrži isti stil uvlačenja koji fajl već koristi (`tab` ili razmaci).
-- Ne radi globalni reformat fajla i ne menjaj linije koje nisu deo zadatka.
-- Ako je stil neujednačen, prati dominantan stil najbližeg koda koji dodaješ.
-
-## 2) Kvalitet i organizacija
-
-- Kod piši maksimalno profesionalno, organizovano i čitljivo, sa jasnim granicama odgovornosti.
-- Kod obavezno odvajaj u logičke celine praznim redom (deklaracije, validacije, transformacije, side-effect delovi, return).
-- Menjaj minimalan broj linija potreban za zadatak.
-- Ne diraj postojeće whitespace-only razlike van opsega izmene.
-- Ne menjaj formatiranje, whitespace, imenovanje promenljivih i stil postojećih metoda van direktnog opsega zadatka.
-- Ako u postojećem kodu primetiš nejasnoće ili stilsku nekonzistentnost, predloži izmene, ali ih ne primenjuj automatski.
-- Novi kod strukturiraj tako da kasnije dodavanje feature-a i izmene budu jednostavni i bezbedni.
-
-## 3) Arhitektura i patterni
-
-- Koristi design pattern-e gde imaju smisla (`Singleton`, `Factory`, `Builder`), samo kada realno poboljšavaju čitljivost, testabilnost i proširivost.
-- Pre uvođenja pattern-a proveri da li već postoji isti ili sličan obrazac u projektu i prati taj postojeći pristup.
-- Ne uvodi pattern formalno ako donosi nepotrebnu kompleksnost.
-
-## 4) Imenovanje
-
-- Poštuj naming konvencije projekta i jezika u kome radiš.
-- Za boolean promenljive nikada ne koristi prefiks `is` (`isValid`, `isActive`, itd.); koristi nazive tipa `valid`, `active`, `enabled`, `exists`.
-
-## 5) JS/TS specifično (primeni samo u JS/TS fajlovima)
-
-- Koristi `;` na kraju izraza.
-- Preferiraj `'single quotes'` za stringove (osim template stringova).
-- Zadrži postojeći razmak u objektima/nizovima/destrukturiranju ako je tako u fajlu.
-- Uvek koristi `async/await` pattern umesto Promise lanaca (`.then/.catch`) gde god je to moguće i smisleno.
-- Ako fajl koristi `require`, nastavi sa `require` (ne prebacuj na `import` bez jasnog razloga).
-- `import`/`require` izraze grupiši u logičke celine i odvajaj svaku celinu praznim redom.
-- Unutar svake celine sortiraj alfabetski (npr. `AccountController` pre `BookController`).
-- Za React/TS zadrži postojeći obrazac komponenti, hook-ova i tipova koji projekat već koristi.
-- Za sve `public` metode obavezno piši kompletan JSDoc komentar iznad metode.
-- JSDoc za `public` metodu treba da sadrži najmanje: `@public`, `@param` (za svaki parametar), `@returns` (osim kada metoda zaista ništa ne vraća), i `@static` kada je metoda statička.
-- Po potrebi dodaj i ostale relevantne tagove (`@throws`, `@async`, `@deprecated`, `@example`) da dokumentacija bude kompletna i korisna.
-
-## 6) Fajlovi i struktura
-
-- Novi fajl imenuj po konvenciji foldera/projekta u koji dodaješ.
-- Ne premeštaj fajlove i ne menjaj naming konvenciju bez eksplicitnog zahteva.
-- Ako postoji konflikt stilova između različitih delova repoa, prati stil ciljanog paketa/fajla.
-
-## 7) Proaktivni predlozi i approval gate
-
-- Ako primetiš bug, potencijalni problem performansi ili efikasnije rešenje, obavezno ga predloži.
-- Svaki predlog napiši jasno: koji deo koda/fajl je problem i zašto je korisno to popraviti (stabilnost, brzina, održavanje, čitljivost).
-- Ako primetiš da postojeći kod ne prati SOLID principe, da je previše kompleksan ili teško razumljiv, obavezno predloži refaktor korake.
-- Za ovakve proaktivne izmene važi approval gate: ne izvršavaj ih automatski, već tek nakon moje eksplicitne potvrde.
-
-## 8) Commit poruke (Conventional Commits)
-
-- Koristi Conventional Commits standard za commit poruke (npr. `feat: ...`, `fix: ...`, `refactor: ...`, `chore: ...`) i piši predlog poruke profesionalno, jasno i u tom formatu.
-- Kada tražim da napišeš commit message za prethodne izmene, obavezno napiši poruku koja jasno obuhvata šta je sve izmenjeno.
-
-## 9) Release notes (`.releases`)
-
-- Kada tražim release, obavezno dodaj novi fajl u `.releases` folder koristeći postojeću strukturu release fajlova tog projekta.
-- Release fajl piši u Markdown formatu sa podebljanim sekcijama i listama, u stilu postojećih fajlova (npr. `**Sekcija**` + `* stavka`).
-- Koristi sledeće ključne sekcije kada su primenljive: `**Bug Fixes**`, `**New Features**`, `**Technical Enhancements**`, `**Other**`, `**Configuration Changes**`.